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Problem 


The  Software  Licensing  Project  (SLP)  team  of  the  Software  Engineering  Institute  (SEI)  was 
created  to  study  legal  issues  related  to  the  government's  acquisition  policy  with  respect  to 
software  and  data  rights.  In  conducting  its  research,  a  primary  focus  of  the  SLP  has  been  the 
government's  problems  in  structuring  licensing  arrangements  for  maintaining  and  enhancing 
software,  that  is,  in  obtaining  sufficient  rights  in  and  documentation  about  software  to  be  able  to 
perform  in-house  maintenance  and  enhancement,  or  to  achieve  competition  for  maintenance  con¬ 
tracts.  To  understand  the  context  within  which  maintenance  and  enhancement  problems  have 
arisen,  the  project  undertook  a  broad  investigation  of  the  government's  software  acquisition 
policy.  In  the  course  of  this  investigation,  we  were  made  aware  of  a  wide  range  of  software 
licensing  problems  being  experienced  by  the  government.  This  report  reflects  this  broad  inves¬ 
tigation  of  the  DoD’s  software  acquisition  policy. 


Approach 

To  initiate  our  investigation  a  series  of  interviews  were  conducted  with  Department  of  Defense 
(DoD)  personnel  and  other  persons  recommended  by  them.  The  Software  Licensing  Project 
investigators  interviewed  about  120  persons.  About  75%  of  our  interviews  were  with  DoD  per¬ 
sonnel  from  the  Sen/ices.  More  of  our  interviews  were  with  Air  Force  than  Army  or  Navy  person¬ 
nel,  but  we  spoke  with  as  many  people  from  the  other  services  as  we  could.  We  spoke  to  contract 
officers,  their  supervisors,  some  contract  policy  makers,  Automatic  Data  Processing  personnel, 
developers  of  advanced  systems,  maintainers  of  systems,  and  lawyers  who  have  handled 
software  data  rights  disputes.  More  than  twenty  of  our  interviewees  were  from  outside  the 
government  (See  Appendix  C.)  Some  were  consultants  to  the  government,  and  some  were 
people  from  industry.  All  "outsiders''  interviewed  were  persons  recommended  by  DoD  personnel. 
The  SEI  researchers  also  reviewed  prior  DoD  reports  on  software  and  technical  data  rights  policy 
as  well  as  cases,  statutes,  treatises,  and  regulations  pertinent  to  the  issues. 


Scope  of  Report 

This  report  does  not  purport  to  be  a  complete  account  of  all  problems  the  Defense  Department  is 
experiencing  vis-a-vis  software  acquisitions  and  data  rights.  What  the  report  does  purport  to  be  is 
an  organized  catalog  of  software  acquisition  problems  reported  by  those  Defense  Department 
personnel  whom  we  interviewed,  along  with  some  assessment  of  their  seriousness.  Virtually  all 
of  the  DoD  people  we  interviewed  believed  the  Department  to  have  some  software  licensing 
problems.  The  majority  of  those  interviewed  -  including  a  majority  of  the  DoD  people  -  believed 
the  government  to  have  many  serious  software  acquisition  problems,  and  strongly  urged  changes 
in  acquisition  policy  to  remedy  the  problems. 


Executive  Summary 


Background 

From  a  technological  standpoint,  software  has  been  a  tremendous  boon  to  U.S.  defense 
capabilities.  Although  many  technological  possibilities  have  yet  to  be  realized,  it  is  not  so  much  in 
terms  of  its  uses  and  capabilities  that  the  Department  of  Defense  currently  finds  software 
troublesome,  but  rather  with  respect  to  more  mundane  issues  such  as  how  to  acquire  and  main¬ 
tain  software  developed  by  private  firms.  The  DoD  seems  not  to  have  understood  software  as  a 
technology  well  enough  yet  to  fashion  a  set  of  rules  relating  to  its  acquisition  and  maintenance 
that  makes  sense  in  terms  of  the  technology  and  the  economics  of  the  industry. 

DoD  sometimes  finds,  for  example,  that  it  is  tempting  to  treat  software  like  it  treats  hardware. 
Software  is,  of  course,  often  an  integral  part  of  an  effective  hardware  system  (e.g.,  the  guidance 
system  for  a  missile.)  It  is,  in  fact,  a  substitute  for  hardware  parts  that  could  be  built  to  implement 
the  same  system  (because  the  system  can  be  implemented  in  software,  buk  is  reduced  and  a 
wider  range  of  capabilities  may  be  attained).  Software  and  hardware  are  both,  in  some  sense, 
end  products;  this  fact  makes  it  seem  as  though  they  ought  to  be  treated  the  same. 

It  may  also  be  tempting  to  treat  software  as  technical  data  (such  as  blueprints,  written  instructions 
relating  to  manufacture  and  maintenance,  and  the  like).  Both  are  in  essence  recorded  infor¬ 
mation.  Whatever  can  be  written  on  paper  can  be  transcribed  into  a  machine-readable  form. 
These  and  other  factors  make  the  similarities  between  software  and  technical  data  seem  strong 
enough  to  suggest  that  a  similar  acquisition  and  maintenance  policy  should  be  employed  with 
both. 

DoD  first  acquired  software  under  its  technical  data  policy.  After  a  period  of  frustration,  it  became 
apparent  that  it  was  inappropriate  to  acquire  software  as  if  it  were  technical  data.  (The  cost  of 
acquiring  government-wide  rights  ••  which  is  what  the  technical  data  rights  policy  provides  -  to 
software  that  was  needed  at  only  one  government  installation  was  impeding  the  acquisition  of 
such  software.)  So  software  (at  least  in  machine-readable  form)  eventually  became  differentiated 
from  technical  data  in  the  regulations,  although  software  and  technical  data  policy  continue  to  be 
somewhat  intertwined.  Thus  while  rights  which  attach  to  proprietary  software  are  different  from 
those  that  attach  to  technical  data,  the  same  standard  data  rights  clause  is  nonetheless  used  to 
acquire  rights  in  both. 

The  question  is  whether  software  has  yet  been  adequately  differentiated  from  technical  data  and 
differentiated  in  the  right  ways.  Has  software  as  a  technology  been  adequately  understood  by 
DoD  and  have  the  legal  rules  and  practices  developed  by  DoD  to  acquire  and  maintain  this 
technology  been  molded  to  conform  to  an  appropriate  understanding  of  the  technology?  DoD's 
rules  and  practices  regarding  software  must  make  sense  not  only  in  terms  of  the  technology  but 
also  in  terms  of  the  government's  needs  to  use  the  technology  and  In  terms  of  the  economics  of 


the  software  industry.  The  policy  also  needs  to  be  clear  and  comprehensible  to  persons  of 
average  intelligence.  The  current  software  acquisition  practices  of  the  DOD  fall  short  of  these 
goals. 

To  be  fair,  it  should  be  said  that  to  develop  the  new  conceptual  apparatus  that  is  necessary  to 
treat  software  appropriately  is  a  difficult  task.  The  temptation  is  to  use  the  nearest  analogue  as 
long  as  one  can,  until  the  problems  with  reliance  on  the  analogue  become  more  pronounced  than 
the  problems  associated  with  developing  a  new  concept.  The  time  has  come  for  the  Department 
of  Defense  to  renounce  the  quasi-technical  data  orientation  of  its  acquisition  practices  toward 
software  and  to  adopt  a  new  policy  that  is  clear  and  coherent,  that  is  no  more  divergent  from 
commercial  practices  than  is  necessary  for  the  achievement  of  the  Defense  Department’s  mis¬ 
sion.  that  is  appropriate  in  terms  of  the  Defense  Department's  need  to  use  the  technology,  and 
that  is  appropriate  in  terns  of  intellectual  property  rights  associated  with  software. 


Report  Structure 

This  report  reflects  the  concerns  of  DoD's  own  people.  Perhaps  the  most  valuable  contribution 
this  report  can  make  is  in  its  structuring  and  giving  expression  to  concerns  of  those  in  the 
Defense  Department  who  have  to  live  with  the  software  licensing  problems  described  in  this 
report.  With  one  or  two  exceptions,  ail  of  the  problems  discussed  in  this  report  are  problems 
identified  by  DoD  personnel. 

The  general  structure  of  this  report  reflects  the  principal  investigator's  judgment  about  the  relative 
importance  of  the  various  categories  of  software  licensing  problems  discussed  in  the  individual 
chapters.  Within  each  chapter  the  order  of  discussion  of  the  problems,  in  general,  is  reflective  of 
their  relative  importance  vis-a-vis  each  other.  The  less  worrisome  the  problems,  the  later,  in 
general,  they  are  discussed  in  the  report.  Below  is  a  summary  of  the  content  of  each  chapter. 


Chapter  1 :  DoD's  Procurement  Regulations 

This  chapter  addresses  a  rather  wide  variety  of  software  licensing  problems  that  DoD  personnel 
have  raised  about  the  existing  procurement  regulations  governing  software  acquisitions.  It 
focuses  most  particularly  on  the  standard  data  rights  clause. 

1.1  Ambiguities  Disadvantaging  the  Government 

There  are  some  ambiguities  and  inconsistencies  in  the  DoD  procurement  regulations  which  seem 
to  woik  to  the  disadvantage  of  the  government.  Four  examples  are  discussed  in  this  chapter. 

1.1.1  The  Apparent  Conflict  between  the  Unlimited  Rights  Provision  and  the  Retention  of 
Copyright  Provision 

The  DoD  standard  data  rights  clause,  in  general,  allows  contractors  to  retain  a  copyright  in 
I  software  developed  at  public  expense.  The  clause  seems  to  give  the  government  "unlimited 
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rights"  in  the  software  in  one  provision  and  only  "governmental  purpose*  rights  in  another  provi¬ 
sion.  This  ambiguity  has  caused  considerable  confusion  among  OoD  personnel.  A  clarification  of 
DoD’s  intent  as  to  the  scope  of  its  rights  when  contractors  retain  copyrights  is  needed. 

1.1.2  The  Failure  to  include  a  Right  to  Make  Derivative  Works  Within  the  Definition  of 
Unlimited  Rights 

The  current  definition  of  unlimited  rights  speaks  only  of  rights  to  "use,”  "duplicate,"  and  "disclose” 
software  developed  at  public  expense.  Derivative  works  rights  are  particularly  important  because 
maintenance,  enhancement,  reuse,  translation,  rehosting  and  retargeting  of  software  are  all  de¬ 
pendent  on  having  a  derivative  works  right.  Considering  the  importance  of  such  a  right  to  DoD,  it 
would  seem  prudent  to  include  such  right  explicitly  in  the  definition  of  "unlimited  rights." 

1.1.3  What  It  Might  and  Might  Not  Mean  to  Hava  Unlimited  Rights  in  Non- Deliverables 
Under  the  DoD  standard  data  rights  clause,  the  government  appears  to  claim  unlimited  rights  in 
items  developed  under  a  government  contract  but  not  required  to  be  delivered  to  the  government. 
Numerous  problems  of  this  sort  have  arisen  in  software  contracts.  The  DoD  would  be  well 
advised  to  revamp  its  acquisition  regulations  to  eliminate  such  confusion,  either  by  eliminating  its 
claim  of  unlimited  rights  in  non-deliverables  or  by  making  a  deferred  ordering  clause  standard. 

1.1.4  The  Apparent  Conflict  between  the  Special  Works  Clause  and  Section  105  of  the 
Copyright  Law 

DoD  policy  calls  for  use  of  the  "special  works"  clause  when  the  government  wants  to  own  and 
control  software  developed  at  public  expense.  The  "special  works"  clause  purports  to  give  the 
government  a  direct  copyright  interest  in  such  software  as  if  it  was  a  "work  made  for  hire."  Unfor¬ 
tunately,  Section  105  of  the  copyright  law  prohibits  direct  acquisitions  of  copyrights  by  the  govern¬ 
ment.  A  copyright  obtained  in  this  manner  might,  therefore,  be  found  invalid  if  challenged  in  a 
court  of  law. 

1 .2  Ambiguities  or  Problems  in  the  Regulations  That  May  Harm 
Industry's  Interests 

There  are  also  some  ambiguities  and  apparent  inconsistencies  in  the  DoD  acquisition  regulations 
which  seem  to  work  to  the  disadvantage  of  industry.  Two  examples  are  discussed. 

1.2.1  Possible  Unlimited  Rights  in  Proprietary  Software  When  Separate  Licensing  Agree¬ 
ments  Are  Not  Made 

The  DoD  acquisition  regulations  provide  that  when  DoD  acquires  software  developed  wholly  at 
private  expense  one  of  two  types  of  restricted  rights  will  apply.  One  set  is  applicable  to  commer¬ 
cial  software  and  one  set  to  other  than  commercial  software  (and  to  commercial  software  whose 
owner  elects  not  to  have  it  treated  as  commercial  software.)  As  to  the  commercial  software,  there 
is  a  standard  set  of  terms  and  restrictions  on  the  government’s  use.  As  to  the  other  software,  it  is 
contemplated  that  other  terms  and  restrictions  can  be  negotiated  by  the  parties,  subject  only  to 
the  requirement  that  the  government  must  always  have  the  four  minimum  rights  set  forth  in  the 
clause.  The  language  of  this  part  of  the  clause  also  seems  to  contemplate  that  a  license  agree¬ 
ment  containing  other  restrictions  will  be  negotiated  and  made  a  part  of  the  government  contract. 
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The  question  is  what  happens  if  the  government  acquires  software  which  the  contractor  has 
decided  to  have  treated  under  the  regulations  as  other  than  commercial  and  a  separate  license 
agreement  has  not  been  negotiated  or  made  part  of  the  oontract?  DoD  personnel  seem  to  have 
differing  opinions  about  this.  Some  believe  that  the  failure  to  negotiate  a  separate  agreement  will 
result  in  the  government  acquiring  unlimited  rights  in  the  proprietary  software,  even  though  but  for 
the  oversight,  the  government  would  settle  for  having  restricted  rights.  Others  feel  that  only  the 
four  minimum  rights  would  attach.  This  is  a  source  of  considerable  concern  to  those  in  industry 
who  recognize  the  possibility  that  the  government  might  claim  broader  rights. 

1.2.2  Unlimited  Rights  in  Software  Documentation  as  to  Other  Than  Commercial  Software. 
The  DoD  acquisition  regulations  seem  also  to  permit  the  government  to  claim  unlimited  rights  in 
documentation  for  privately  developed  software  insofar  as  it  can  be  characterized  as  instructional 
material  necessary  to  maintenance  of  a  system.  While  the  restricted  rights  provision  pertaining  to 
commercial  software  seems  to  shield  commercial  software  documentation  from  the  broad  reach 
of  this  provision,  there  is  no  comparable  basis  for  claiming  an  exemption  from  unlimited  rights 
treatment  for  the  documentation  to  software  treated  as  other  than  commercial  software.  Many 
industry  people  are  quite  nervous  about  delivering  software  documentation  to  the  government  for 
fear  they  will  lose  all  proprietary  rights  in  the  documentation. 

1 .3  The  Need  for  More  Precise  Definitions 

During  interviews  with  DoD  personnel,  we  found  confusion  concerning  certain  definitions  used  in 
the  DoD  acquisition  regulations.  Some  of  this  confusion  is  the  result  of  ambiguity  and  imprecise 
wording.  In  other  instances,  crucial  concepts  are  simply  not  defined.  Some  of  the  more  significant 
problems  include: 

1 .  The  lack  of  an  adequate  definition  for  the  term  unlimited  rights.  There  is  con¬ 
siderable  uncertainty  within  the  DoD  as  to  whether  unlimited  rights  is  more  akin  to 
an  ownership  interest  or  a  license  right.  We  conclude  that  unlimited  rights  gives  the 
government  a  kind  of  license  right. 

2.  The  lack  of  any  definition  for  the  term  governmental  purpose.  The  DoD  acquisition 
regulations  provide  for,  in  certain  instances,  a  license  for  governmental  purposes, 
but  fail  to  provide  guidance  as  to  what  the  scope  of  such  license  might  be. 

3.  The  term  privately  developed  software  needs  to  be  defined.  The  scope  of  this  tern 
is  a  highly  controversial  issue,  and  input  from  industry  on  this  matter  would  seem 
advisable.  To  neglect  to  define  the  term,  however,  only  ensures  conflict  between 
industry  and  government  as  to  its  meaning. 

4.  The  existence  of  two  types  of  restricted  rights  in  the  acquisition  regulations  does  not 
seem  to  serve  any  purpose  sufficient  to  justify  the  confusion  it  creates. 

1.4  Issues  Not  Addressed  in  the  DoD  Regulations 

There  are  several  issues  relevant  to  the  procurement  of  software  which  are  not  addressed  by  the 
existing  DoD  acquisition  regulations.  Since  DoD's  personnel  need  guidance  about  how  these 
issues  should  be  dealt  with,  provision  should  be  made  for  them  in  the  regulations.  Among  the 
most  critical  areas  not  adequately  dealt  with  by  the  present  DoD  acquisition  regulations  are: 
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1)  How  to  acquire  tights  in  or  access  to  CAD/CAM  programs  used  in  the  development  of 
software  for  the  DoD;  2)  Acquiring  rights  to  local  area  network  usage  of  software;  3)  Acquiring 
rights  in  semiconductor  chip  designs;  4)  Acquiring  trademark  rights  in  software;  and  5)  The 
effect  of  ’shrink  wrap"  licenses  accompanying  software  delivered  with  restrictive  notices. 

Chapter  1  also  offers  some  suggestions  on  how  DoD  might  revise  its  software  acquisition  regula¬ 
tions  to  avoid  some  of  the  pitfalls  discussed  in  the  chapter,  and  makes  recommendations  as  to 
how  the  data  rights  clause  might  be  restructured  so  as  to  achieve  greater  simplicity  and  clarity. 


Chapter  2:  Software  Maintenance  and  Enhancements 

This  chapter  discusses  a  range  of  licensing  problems  that  DoD  personnel  identified  as  software 
maintenance  and  enhancement  problems.  One  of  the  reasons  why  maintenance  and  enhance¬ 
ment  problems  may  be  so  difficult  to  solve  is  that  they  are  not  one  but  many  problems. 

The  chapter  begins  with  a  discussion  of  the  set  of  problems  that  the  RFP  for  the  Software  En¬ 
gineering  Institute  initially  identified  as  difficulties  DoD  was  having  in  getting  sufficient  rights  in 
and  documentation  about  software  to  enable  the  software  to  be  competitively  maintained  or  en¬ 
hanced,  or  sometimes  to  be  maintained  in-house. 

The  report  concludes  that  obtaining  rights  in  the  government  to  modify  software  is  not  a  current 
software  licensing  problem  of  the  Defense  Department.  The  DoD  procurement  regulations  require 
that  in  all  software  acquisition  contracts  for  proprietary  software  the  government  must  at  minimum 
get  the  right  to  modify  the  software.  This  regulatory  authority  is  important  since  copyright  law 
might  otherwise  prohibit  the  modification  of  software  without  the  permission  of  the  copyright 
owner  to  make  a  "derivative  work."  The  DoD  regulations  appear  to  be  sufficient  to  secure  for  the 
DoD  the  right  to  modify  software  it  acquires. 

Getting  adequate  software  documentation  seems  to  be  the  major  software  maintenance  and  en¬ 
hancement  problem  experienced  by  the  Defense  Department.  The  reasons  for  this  problem  in¬ 
clude;  1)  lack  of  farsightedness  in  acquiring  sufficient  documentation,  2)  lack  of  diligence  in 
supervising  delivery  of  documentation,  3)  lack  of  adequate  inspection  as  to  attachment  of 
restrictive  notices,  4)  poor  quality  of  some  documentation  delivered,  and  5)  unwillingness  of 
some  companies  to  provide  certain  documentation  to  the  government. 

Without  adequate  documentation,  maintenance  and  enhancement  of  software  will  be  at  least 
more  difficult,  and  perhaps  impossible. 

Under  the  DoD  procurement  regulations,  the  government  obtains  the  right  to  modify  software,  but 
does  not  automatically  acquire  the  right  to  sublicense  its  modification  right  to  others.  If  the 
government  has  unlimited  rights  in  software,  obtaining  competition  in  software  maintenance  and 
enhancement  contracts  may  not  be  difficult.  If,  however,  the  government  has  only  restricted  rights 
as  to  software  and  limited  rights  as  to  documentation,  it  will  probably  have  to  do  any  maintenance 
and  enhancement  work  itseif,  or  through  the  firm  that  originally  developed  the  software.  This  firm 


may  have  incentives  not  to  give  up  its  "sole  source*  position  as  to  maintenance  and  enhance¬ 
ments,  unless  provision  has  been  made  for  this  during  the  original  competition  for  the  develop¬ 
ment  contract.  The  chapter  recommends  a  variety  of  mechanisms  DoD  might  use  to  better  plan 
for  competitive  maintenance  of  software  when  this  is  desired.  Escrowing  of  software  documen¬ 
tation  is  discussed  as  a  possible  mechanism  to  ensure  that  DoD  will  have  access  to  the 
documentation  under  specified  conditions,  while  at  the  same  time  ensuring  that  the  proprietary 
rights  of  the  developer  are  respected. 

In  addition  to  acquiring  written  documentation  and  rights  to  modify,  adequate  maintenance  and 
enhancement  of  software  will  often  require  access  to  the  tools’  which  were  used  in  the  develop¬ 
ment  of  the  software.  Software  tools  and  CAD/CAM  programs  are  increasingly  being  used  to 
develop  software.  Because  of  the  commercial  value  of  such  tools,  contractors  are  reluctant  to 
license  the  government  to  acquire  rights  in  software  tools  or  in  some  cases  even  access  to  them 
because  of  objections  to  the  government's  standard  data  rights  policies.  If  DoD  wishes  to  obtain 
rights  in  or  access  to  the  highest  quality  software  tools  and  CAD/CAM  programs  that  industry  has 
to  offer,  it  may  need  to  adjust  its  data  rights  policy.  For  example,  it  might  make  arrangements 
whereby  an  intermediary  firm  could  acquire  the  material  on  the  government’s  behalf,  subject  to 
more  restrictions  than  the  government’s  standard  policy  permits. 

Other  issues  discussed  in  Chapter  2  that  relate  to  software  modifications  include  the  effect  of 
modification  by  the  government  on  pre-existing  restrictions,  whether  restrictions  will  attach  to 
modified  portions,  the  significance  of  the  regulatory  duty  not  to  prepare  similar  software,  the 
ramifications  of  reverse  engineering  of  software,  deciding  about  ownership  rights  in  modifications, 
and  the  effect  on  warranties  when  software  is  modified. 


Chapter  3:  The  Need  for  Better  Training  about  Software,  Data  Rights, 
And  Intellectual  Property  Law 

This  chapter  examines  the  need  for  additional  training  of  DoD  contracting  personnel  with  regard 
to  both  software  technology  and  the  government's  data  rights  policy. 

Although  DoD  is  fortunate  to  have  many  dedicated,  competent  individuals  among  its  procurement 
personnel,  these  individuals  reported  that  they  feel  inadequately  trained  for  the  role  they  have  to 
perform  in  complex  software  acquisition  contracts.  Much  of  the  software  that  the  contracting  per¬ 
sonnel  must  acquire  is  ’state  of  the  art’  technology.  Communication  between  procurement  per¬ 
sonnel  and  users  seems  to  be  infrequent,  which  makes  maintenance  and  supportability  planning 
more  difficult.  Often  procurement  personnel  have  no  training  in  software  technology,  software  life 
cycles,  or  software  support  systems.  Further,  the  procurement  regulatory  structure  within  which 
the  negotiation  process  must  proceed  --  especially  as  to  data  rights  --  is  quite  complex.  Finally, 
the  turnover  rate  among  procurement  personnel  is  high,  which  only  aggravates  the  situation. 

Given  the  difficult  environment  within  which  contracting  personnel  must  operate,  it  is  not  surpris¬ 
ing  that  there  have  been  problems  related  to  the  acquisition  of  software.  Contracting  personnel 


need  greater  training  in  the  area  of  software  procurement  so  as  to  achieve  a  better  understanding 
of  the  technology  they  are  charged  with  acquiring.  Personnel  practices  need  to  be  improved  to 
retain  those  personnel  who  have  acquired  some  training  and  experience.  Improved  communica¬ 
tion  mechanisms  between  those  acquiring  a  system  and  those  who  will  use  the  system  need  to 
be  developed  and  implemented.  Chapter  3  discusses  ways  in  which  such  changes  might  be 
accomplished. 


Chapter  4:  Reusability  and  Other  Software  Derivative  Works 
Problems 

This  chapter  considers  a  host  of  problems  that  arise  when  'derivative  works*  are  created  from  an 
original  piece  of  software.  Particular  attention  is  given  to  concerns  of  DoD  personnel  about 
software  reusability. 

The  term  software  reuse  has  several  meanings.  A  common  factor  to  each  of  these  meanings,  be 
it  a  project  which  reuses  a  particular  module  of  code  or  one  which  reuses  the  logic,  structure 
and/or  design  of  a  program,  is  that  it  may  be  an  instance  of  the  creation  of  a  derivative  work 
which  may  involve  the  complex  regulations  of  the  copyright  law. 

The  copyright  law  gives  to  the  holder  of  a  copyright  certain  exclusive  rights  in  the  subject  matter 
of  the  copyright.  Included  among  these  exclusive  rights  is  the  right  to  make  derivative  works 
based  on  the  original  copyrighted  item.  For  the  government  to  make,  or  have  made  for  it, 
software  which  is  in  some  way  derived  from  a  program  in  which  another  party  holds  a  copyright, 
without  having  first  obtained  the  permission  of  the  copyright  holder,  raises  the  possibility  that  the 
government  will  be  found  to  have  infringed  the  copyright.  As  a  result,  the  government  may  be 
prohibited  from  making  use  of  the  newly  developed  software. 

The  potential  impact  of  the  derivative  works  right  for  software  is  broader  even  than  its  effect  on 
software  reuse  projects.  Virtually  any  effort  which  in  some  way  alters  software  and  causes  it  to 
act  in  a  way  different  from  its  original  function  may  be  found  to  be  the  creation  of  a  derivative 
work  should  the  copyright  holder  challenge  the  government’s  actions  in  court.  Thus,  even  basic 
maintenance  and  enhancement  efforts,  as  well  as  rehosting,  and  retargeting,  to  the  extent  that 
the  changes  may  be  said  to  improve  the  software,  might  be  found  to  be  derivative  works  -  the 
creation  of  which  infringes  the  rights  of  the  copyright  holder.  Such  projects  also  raise  questions  as 
to  ownership  rights  in  the  newly  created  product. 

This  chapter  discusses  these  issues  at  some  length,  noting  that  the  legal  issues  which  arise  in 
the  context  of  the  derivative  works  right  of  the  copyright  law  are  as  significant  as  the  technologi¬ 
cal,  sociological  and  cataloguing  problems  which  must  be  confronted  when  dealing  with  software 
reusability.  These  are  issues  which  the  DoD  should  consider  in  preparing  to  undertake  such 
projects. 
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Chapter  5:  Government  Ownership  of  Copyrights 

DoD  is  running  a  risk  when  it  employs  its  'special  works*  clause  to  attempt  to  take  a  direct 
copyright  interest  in  software.  This  chapter  proposes  adoption  of  a  less  risky  strategy  for  obtain¬ 
ing  ownership  rights  in  software. 

When  DoD  wants  to  take  a  direct  ownership  interest  in  a  work  prepared  for  it  by  a  private  contrac¬ 
tor,  the  DoD  FAR  SUPP  directs  that  the  'special  works'  clause  be  used  in  the  development 
contract.  The  clause  in  effect  claims  a  direct  copyright  for  the  government  under  the  copyright 
'work  made  for  hire*  doctrine.  We  understand  that  this  'special  works”  clause  has  been  used  in  a 
number  of  DoD  software  development  contracts.  Indeed,  it  appears  that  a  deviation  would  be 
required  to  attempt  take  a  copyright  interest  in  any  other  manner. 

The  problem  with  use  of  the  special  works  clause  for  this  purpose  is  that  the  copyright  law 
specifically  prohibits  the  government  from  taking  direct  ownership  rights  in  copyrighted  works. 
The  legislative  history  of  this  section  reflects  that  Congress  considered  the  issue  of  copyright 
ownership  of  works  prepared  for  the  government  by  contractors  and  decided  that  while  agencies 
could  decide  that  a  contractor  might  be  permitted  to  retain  a  copyright,  the  government  could  not 
get  direct  copyright  ownership  in  works  prepared  for  it. 

Copyright  law  permits  the  government  to  own  copyrights  only  by  assignment,  bequest,  and  the 
like.  Taking  a  copyright  as  if  the  work  was  'made  for  hire'  is  not  the  same  as  taking  a  copyright  by 
assignment  or  bequest.  What  the  "special  works"  clause  will  be  effective  in  doing  is  precluding 
the  contractor  from  claiming  any  ownership  rights  in  the  software.  A  copyright  obtained  directly  in 
the  DoD  pursuant  to  this  clause  may  very  well  be  found  invalid  if  challenged  in  court. 

If  the  Defense  Department  wishes  to  obtain  a  copyright  interest  in  software,  we  recommend  that 
they  adopt  an  assignment  approach  similar  to  that  adopted  by  NASA  and  that  proposed  under  the 
new  FAR  whereby  the  contractor  takes  the  copyright  and  then  assigns  it  to  the  government. 
Alternatively,  the  government  might  consider  working  for  a  legislative  change  which  would  permit 
the  government  to  directly  obtain  a  copyright  in  software  developed  for  it  under  government  con¬ 
tract. 


Chapter  6:  Problems  Arising  from  the  Government’s  Trademark 
Rights  with  Regard  to  Software 

The  Department  of  Defense  is  increasingly  claiming  trademark  rights  in  software  and  related 
technology.  Acquiring  and  maintaining  trademark  rights  is  a  specialized  legal  matter.  There 
seems  to  be  little  expertise  within  DoD  as  to  the  scope  and  proper  use  of  the  government's 
trademark  rights  in  words  (such  as  'Ada")  used  in  connection  with  software.  DoD  personnel 
seemed  to  be  unclear  as  to  the  type  of  mark  ’Ada"  is  (i.e.,  a  certification  mark  or  a  trade  mark), 
who  owns  the  mark  (i.e.,  the  U  S.  government,  DoD  or  the  Ada  Joint  Program  Office),  and  even 
as  to  what  rights  attach  to  a  trade  mark  or  certification  mark. 


A  mark  cannot  be  both  a  trade  mark  and  a  certification  mark;  it  must  be  one  or  the  other.  It  is 
important  to  know  which  type  of  mark  you  have  since  different  rights  attach  depending  on 
whether  it  is  a  trade  mark  or  certification  mark.  If  one  tries  to  enforce  rights  one  does  not  in  fact 
have  in  the  mark,  or  otherwise  misuses  one's  rights  in  the  mark,  one  runs  the  risk  of  losing  that 
mark. 

A  trademark  can  only  be  owned  by  persons  who  manufacture  or  distribute  goods  bearing  that 
particular  mark.  By  contrast,  the  owner  of  a  certification  mark  is  prohibited  from  being  either  a 
manufacturer  or  distributor  of  goods  for  which  certification  is  sought.  Unlace  a  trademark,  a  cer¬ 
tification  mark  does  not  signify  the  source  of  goods;  it  signifies  only  that  certain  goods  have  met  a 
certain  standard.  To  obtain  rights  in  a  certification  mark,  one  must  register  the  mark  with  a  federal 
agency,  and  develop  certain  standards  that  others  must  meet  to  be  certified  to  use  the  mark. 

Since  the  DoD  intends  to  use  its  rights  in  the  word  "Ada"  to  establish  certain  standards  which 
must  be  met  before  an  item  can  be  certified  as  an  "Ada*  compiler  or  whatever,  it  appears  that 
"Ada*  is  a  certification  mark  rather  than  a  trade  mark.  If  this  assumption  is  correct,  then  it  is 
important  that  the  government  not  take  ownership  in  software  using  this  mark.  It  must  also  police 
use  of  the  mark  by  non-certified  parties.  It  must  make  sure  that  the  mark  is  not  used  for  other 
than  certification  purposes.  And  it  must  not  deny  certification  to  qualified  parties.  Failure  to  follow 
these  guidelines  could  result  in  loss  of  a  certification  mark.  It  also  must  develop  standards  for 
everything  it  wishes  to  be  able  to  certify  (not  just  compilers). 


Chapter  7:  A  Hypothetical  Illustration  of  Software  Licensing 
Problems  under  the  Existing  Regulations 

This  chapter  uses  a  hypothetical  software  environment  system  developed  at  DoD  expense  to 
illustrate  some  of  the  problems  discussed  in  previous  chapters.  It  may  be  easier  to  comprehend 
the  seriousness  of  and  interrelationship  of  these  several  problems  by  examining  them  through  a 
hypothetical  example. 

For  instance,  this  chapter  points  out  serious  problems  that  may  arise  due  to  the  conflict  between 
the  unlimited  rights  provision  and  copyright  retention  clause  of  the  DoD  acquisition  regulations, 
questions  as  to  ownership  rights  in  modified  software  which  has  been  derived  from  software  in 
which  a  contractor  holds  a  copyright,  the  need  for  an  adequate  definition  of  the  term 
"governmental  purpose,"  and  issues  related  to  government  ownership  of  copyright,  patents, 
trademarks,  warranties,  and  export  controls.  Although  this  chapter  represents  a  hypothetical  ex¬ 
ample,  the  problems  it  illustrates  are  very  real.  Given  the  number  of  ambitious  software  engineer¬ 
ing  projects  which  the  DoD  has  been  funding  in  recent  years,  it  would  be  wise  to  solve  the 
problems  this  Chapter  discusses  before  they  erupt  into  litigation. 


Chapter  8:  Subcontractor  Flowdown  Problems 

This  chapter  raises  a  set  of  concerns  voiced  by  DoD  personnel  about  the  extent  of  the 
government's  rights  when  prime  contractors  fail  to  obtain  from  a  subcontractor  the  full  set  of  rights 
that  the  government  had  bargained  for  from  the  prime.  The  chapter  suggests  that  the  government 
may  be  able  to  enforce  rights  under  mandatory  clauses  as  against  the  subcontractors,  but  not 
those  deriving  from  discretionary  or  specially  written  clauses. 

Certain  clauses,  such  as  the  standard  data  rights  clause,  are  required  to  be  used  in  DoD  software 
acquisition  contracts  unless  a  deviation  has  been  obtained  from  the  DAR  Council.  If  a  prime 
neglects  to  insert  the  standard  data  rights  clause  in  a  subcontract  with  a  software  developer  or 
negotiates  with  the  subcontractor  for  less  rights  than  the  mandatory  clause  requires  that  the 
government  have,  it  would  seem  that  the  government  could  enforce  the  standard  data  rights 
clause  against  the  subcontractor.  The  clause  is  a  government  regulation  and  is  required  by 
regulation  to  be  inserted  in  all  DoD  software  contracts  unless  a  deviation  has  been  obtained. 
Subcontractors  would  likely  be  held  to  have  constructive  notice  of  this. 

There  are  many  clauses  used  in  government  contracts  that  are  not  mandatory.  The  "special 
works"  clause  is  an  example  of  a  standard  discretionary  clause.  Other  clauses  are  specially 
drafted  for  particular  contracts  (e.g.,  clauses  defining  the  scope  of  warranty  rights  in  software).  If 
a  prime  contractor  has  promised  the  government  to  obtain  certain  rights  under  a  discretionary 
clause,  and  the  prime  either  is  unable  or  neglects  to  secure  a  commitment  for  such  rights  from  a 
subcontractor,  it  seems  unlikely  that  the  government  could  enforce  against  the  subcontractor  the 
rights  it  had  expected  the  prime  to  get  for  it. 


Chapter  9:  Limitations  on  Governmental  Action 

This  chapter  discusses  the  risk  of  injunctive  relief  being  entered  against  the  government  in  dis¬ 
putes  over  rights  in  software  held  as  a  trade  secret  by  its  owner.  The  chapter  identifies  a  number 
of  situations  in  which  the  government  might  be  able  to  successfully  avoid  injunctive  remedies,  but 
notes  that  certain  recent  legal  precedents  have  created  a  serious  risk  of  injunctive  relief  in 
software  disputes,  from  which  DoD  may  not  be  shielded  by  various  statutes  on  which  it  has 
customarily  relied  to  avoid  injunctions. 

Most  software  intended  for  commercial  distribution  is  held  as  a  trade  secret  by  the  developer. 
Although  the  government  has  statutory  authority  to  infringe  patents  and  copyrights,  it  does  not 
have  similar  authorization  to  appropriate  trade  secrets  against  the  owner’s  wishes.  Indeed,  there 
is  a  criminal  statute  that  penalizes  any  federal  employee  who  discloses  confidential  information 
claimed  as  a  company’s  trade  secret  without  authorization.  Some  DoD  lawyers  expressed  con¬ 
cern  about  an  injunction  issuing  against  governmental  use  of  the  software.  This  they  felt  might 
occur  in  the  context  of  litigation  between  a  software  producer  and  the  government  over  trade 
secret  software.  This  is  a  risk  that  the  government  has  not  previously  had  to  confront  as  to  its 
equipment  because  hardware,  if  protected  by  a  form  of  intellectual  property  law,  would  generally 
be  protected  only  by  patents,  which  the  government  could  infringe.  (Trade  secrets  generally 
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cannot  reside  in  hardware  since  reverse  engineering  of  the  hardware  would  readily  reveal  any 
such  ’secrets.’)  Because  software  tends  to  be  protected  through  both  copyright  and  trade  secret 
law,  there  is  good  reason  to  be  concerned  about  the  injunctive  potential,  although  in  some  situa¬ 
tions  the  government  might  be  able  to  avoid  the  issuance  of  an  injunction. 

An  additional  basis  for  concern  about  injunctive  relief  has  been  expressed  because  of  a  series  of 
recent  federal  court  decisions  which  have  suggested  that  injunctive  relief  may  be  available  to 
prevent  the  government  from  releasing  material  in  which  it  claims  unlimited  rights  but  which  is 
claimed  as  a  trade  secret  by  its  producer.  This  danger  was  thought  by  several  DoD  lawyers  to  be 
particularly  acute  in  disputes  with  subcontractors  because  until  recently  there  has  been  no  formal 
procedure  under  the  Contracts  Dispute  Act  for  handling  controversies  about  data  rights  as  be¬ 
tween  a  subcontractor  and  the  government.  Some  thought  that  the  Contract  Disputes  Act  should 
be  amended  to  eliminate  this  risk.  One  provision  of  the  1985  DoD  Authorization  Act  may  partially 
address  this  problem. 


Chapter  10:  CAD/CAM  Programs 

This  chapter  poses  a  series  of  questions  that  have  been  troubling  DoD  personnel  about  computer 
aided  design  and  computer  aided  manufacturing  (CAD/CAM)  programs. 

CAD/CAM  programs  are  being  increasingly  used  in  both  the  design  and  manufacture  phase  of 
DoD  funded  projects.  Because  of  the  potential  commercial  value  of  CAD/CAM  programs,  and  the 
widespread  industry  concern  about  the  government’s  ability  to  safeguard  valuable  commercial 
information,  some  contractors  are  reluctant  to  provide  DoD  the  CAD/CAM  programs  used  to 
design  and  manufacture  items  developed  under  DoD  projects.  Without  access  to  the  tool  used  to 
develop  a  product,  the  maintenance  and  enhancement  of  that  item  may  be  more  difficult,  and 
perhaps  impractical. 


One  potential  solution  to  this  dilemma  is  that  DoD  may  be  able  to  contract  for  obtaining  access  to 
the  CAD/CAM  program  (although  perhaps  not  a  copy  of  it)  on  an  ’as  needed*  basis  for  necessary 
maintenance  and  enhancements.  This  would  provide  the  DoD  with  information  needed  for 
modifications  while  at  the  same  time  protecting  the  contractor's  interests  in  commercially  exploit¬ 
ing  its  valuable  program.  For  such  an  arrangement  to  be  satisfactory,  however,  the  government 
would  need  to  have  assurances  that  it  would  have  continual,  irrevocable  access  to  the  original 
program  used  to  develop  and/or  manufacture  the  item  acquired. 

It  may  be  beneficial  to  the  government  for  the  responsibility  for  maintaining  the  CAD/CAM 
program  to  remain  with  the  contractor.  Although  with  an  access  arrangement  the  government 
would  lose  an  element  of  control  by  not  having  physical  possession  of  the  program,  it  might  gain 
in  terms  of  ease  of  retrieval  and  not  having  to  trouble  itself  with  configuration  management  for  the 
system. 

A  major  problem  with  making  arrangements  for  DoD  to  get  access  tc  CAD/CAM  programs  is  that 


f.AV.V.V.V: 


the  DoD  acquisition  regulations  do  not  provide  any  guidance  about  such  issues.  Access  appears 
to  be  less  than  the  set  of  minimum  restricted  rights  that  the  standard  data  rights  policy  con¬ 
templates  as  mandatory  for  software  acquisitions.  DoD  needs  to  develop  a  better  regulatory 
policy  to  enable  it  to  benefit  fully  from  this  relatively  new  and  powerful  technology. 


Chapter  11:  Software's  Hybrid  Nature 

This  chapter  briefly  explores  how  software  differs  from  hardware  and  from  technical  data.  One  of 
the  many  ramifications  of  the  hybrid  nature  of  software  --  partly  a  "writing  *  partly  a  "machine  part" 
~  has  to  do  with  whether  DoD  may  be  able  to  claim  warranties  in  software  delivered  to  it  under 
contracts  silent  as  to  the  issue  of  warranties. 

Implied  warranties  --  as  of  merchantability  or  fitness  for  a  particular  purpose  ~  do  not  attach  to 
services;  they  may  attach  to  "goods."  If  more  akin  to  hardware,  software  would  appear  to  be 
within  the  meaning  of  "goods."  If  characterized  as  being  more  lice  technical  data,  software  would 
appear  to  be  more  in  the  nature  of  a  service.  Thus,  the  characterization  of  software  can  have 
significant  implications  with  respect  to  the  question  of  whether  or  not  implied  warranties  will  at¬ 
tach.  We  conclude  that  implied  warranties  may  attach  to  software  delivered  to  DoD,  even  though 
government  contracts,  strictly  speaking,  are  not  governed  by  the  Uniform  Commercial  Code  from 
whence  such  implied  warranties  as  merchantability  and  fitness  for  a  particular  purpose  originally 
came. 


Chapter  12:  Semiconductor  Chip  Protection 

This  chapter  describes  the  new  form  of  intellectual  property  law  that  Congress  created  in  1984 
which  gives  a  set  of  exclusive  rights  to  owners  of  chip  circuitry  designs.  The  new  chip  protection 
law  resembles  patent  and  copyright  law  in  some  ways,  but  it  is  unique  in  some  respects.  It  also 
reports  on  how  the  new  law  may  affect  DoD’s  software  acquisitions. 

The  DoD  acquisition  regulations  make  no  reference  to  the  new  chip  law.  There  is  no  existing 
mechanism,  for  example,  by  which  DoD  can  take  rights  in  the  chip  designs  developed  for  it.  The 
chip  law.  like  the  copyright  law,  contains  a  provision  prohibiting  the  government  from  directly 
obtaining  protection  under  that  law.  Thus,  to  obtain  protection  in  a  chip  developed  by  the  govern¬ 
ment  or  by  a  contractor  for  the  government,  it  appears  that  the  DoD  would  have  to  employ  an 
assignment  approach  such  as  that  discussed  in  Chapter  5  dealing  with  government  ownership  of 
copyright. 

An  important  way  in  which  protection  under  the  chip  law  differs  from  protection  under  the 
copyright  law  is  that  section  1498  of  title  28  U.S.C.  shields  the  government  from  an  injunction  in 
cases  where  the  government  is  found  to  have  infringed  a  copyright  or  a  patent;  no  such  protec¬ 
tion  is  available  to  the  government  for  infringement  of  a  chip  mask.  Thus,  the  holder  of  protection 
under  the  chip  law  might  be  able  to  obtain  an  injunction  against  the  government  prohibiting  further 
use  of  an  infringing  chip,  whereas  such  relief  would  not  be  available  against  the  government  as  to 


works  protected  under  the  copyright  or  patent  law.  Since  there  are  many  government  projects 
which  will  likely  make  use  of  specially  designed  chips,  it  would  seem  advisable  for  the  DoD  to 
consider  adopting  a  policy  that  takes  note  of  the  chip  law. 


Chapter  13:  Approach  to  Solving  DoD’s  Software  Licensing 
Problems 

This  chapter  offers  some  suggestions  about  an  approach  that  DoD  might  consider  undertaking  to 
resolve  the  software  licensing  problems  raised  in  this  report. 

There  is  no  easy  way  to  solve  all  of  DoD’s  software  licensing  problems.  There  are  too  many 
different  types  of  problems,  stemming  from  too  many  different  causes.  There  is  also  too  much 
money  at  stake  for  any  "quick  fix"  solution  to  work.  The  situation  is  made  more  difficult  by  the 
strained  relationship  which  currently  exists  between  industry  and  government  with  regard  to 
software/data  rights  issues. 

That  does  not  mean,  however,  that  none  of  DoD’s  software  licensing  problems  can  be  resolved 
quickly  or  easily;  nor  does  it  mean  that  most  of  of  its  problems  are  unsolvable.  Removing  the 
ambiguities  and  inconsistencies  from  the  existing  procurement  regulations,  for  example,  would 
require  some  relatively  minor  alterations  to  those  regulations.  Although  some  of  DoD’s  software 
licensing  problems  may  be  more  resistant  to  solution  than  others,  there  may  well  be  ways  of 
approaching  even  the  major  problems  that  would  be  more  constructive  than  other  approaches 
which  might  be  taken. 

The  crucial  point  is  that  not  all  of  DoD's  software  licensing  problems  can,  or  should  be  treated  in 
the  same  way.  There  are  certain  problems  which  DoD  has  more  control  over  than  it  does  others. 
In  allocating  resources,  we  suggest  that  DoD  place  a  greater  emphasis  on  those  problems  which 
are  more  readily  within  its  control,  and,  therefore,  could  be  more  easily  resolved.  There  are  also 
some  software  licensing  problems  that  are  by  their  nature  more  amenable  to  change  than  others. 
Again,  in  allocating  the  time  and  resources  of  DoD  personnel  to  addressing  software  licensing 
problems,  we  advise  that  DoD  attempt  to  focus  its  limited  resources  on  those  problems  which  are 
most  likely  to  be  impacted  by  such  an  effort. 

The  reality  of  today  is  that  many  firms  on  the  "cutting  edge"  of  software  technology  can  survive 
without  doing  business  with  the  government.  The  DoD  needs  the  latest  technology  in  order  to 
maintain  a  strong  defense  and  military  capability.  Thus,  it  seems  clear  that  in  many  cases.  DoD 
needs  industry  more  than  industry  needs  DoD.  Given  this  situation,  it  seems  incumbent  upon 
DoD  to  make  some  effort  to  improve  the  strained  lines  of  communication  between  it  and  private 
industry. 

Our  conclusion  is  that  industry  people  is  willing  to  meet  with  DoD  in  an  effort  to  resolve  dif¬ 
ferences  which  exist.  It  is  clearly  within  the  power  and  control  of  DoD  to  pursue  such  communica¬ 
tions,  and  would  likely  be  one  of  the  most  beneficial  steps  DoD  could  take  toward  resolving  many 
of  its  software  licensing  problems. 
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1 .  Problems  Arising  from  the  DoD  Data  Rights  Regulations 


There  is  considerable  support  within  DoD,  especially  among  its  non-lawyers,  for  a  major  overhaul 
of  the  regulations  with  respect  to  data  rights  affecting  software  procurements.  Industry  also 
tended  to  favor  a  major  overhaul.  Many  of  the  DoD  procurement  people  (and  some  of  its  lawyers) 
would  like  to  see  the  regulations  adopt  a  simpler,  more  reasonable  approach  to  software  licens¬ 
ing,  one  more  like  that  used  in  private  sector  software  transactions.  Some  of  the  DoD  personnel 
to  whom  we  spoke  regarded  the  basic  approach  of  the  DoD  data  rights  regulations  as  sound, 
although  they  also  tended  to  think  that  there  were  some  problems  with  some  details  of  the  regula¬ 
tions  as  applied  to  software. 

We  believe  that  there  are  some  serious  problems  with  specific  details  of  the  present  regulations 
as  they  bear  on  software  licensing,  some  of  which  have  erupted  in  specific  instances.  The  first 
several  sections  of  this  chapter  discuss  specific  aspects  of  the  DoD  procurement  regulations  as 
they  bear  on  software  licensing  problems  raised  by  DoD  personnel.  At  a  minimum,  some  revi¬ 
sions  in  the  regulations  to  avoid  these  problems  would  seem  wise. 

To  us,  the  DoD  software  procurement  regulations  resemble  one  of  those  old  1950's  model  com¬ 
puters  that  tend  to  go  "down*  a  lot  because  of  burned  out  vacuum  tubes  and  other  equipment 
failures.  If  the  question  is  can  it  be  fixed  up  yet  again,  the  answer  is  probably  yes.  If  the  question 
is  instead  whether  it  is  time  to  get  a  new  computer,  the  answer  is  probably  also  yes.  The  current 
regulations  are  overly  complicated,  ambiguous  and  inconsistent  in  a  number  of  ways,  not  only  in 
terms  of  commercial  practices  but  also  in  terms  of  the  precepts  of  intellectual  property  law.  Revis¬ 
ing  the  format  of  the  regulations  could  not  only  simplify,  clarify  and  update  procurement  practices, 
but  also  serve  to  improve  relations  with  industry.  The  final  subsection  of  this  chapter  discusses 
the  reasons  we  regard  the  proposed  FAR  data  rights  regulations  as  better  serving  the  DoD's 
interests  than  the  current  DoD  FAR  SUPP  and  its  proposed  revisions  do. 

Finally,  it  should  be  noted  that  while  this  chapter  and  several  subsequent  chapters  place  par¬ 
ticular  emphasis  on  the  copyright  law  as  a  means  by  which  contractors  can  protect  certain  inter¬ 
ests  in  software  they  have  developed,  they  do  so  because  this  reflects  the  approach  used  in  the 
DoD  procurement  regulations.  In  industry,  trade  secret  protection,  not  copyright,  is  often  the 
preferred  mode  for  protecting  one's  intellectual  property  rights  in  software  and  technical 
documentation.  The  DoD  procurement  regulations,  however,  do  not  recognize  the  existence  of 
trade  secret  protection  for  software  or  technical  data  ( [8]  pp  430-31).  The  regulations  instead 
create  a  kind  of  contractual  intellectual  property  right  in  them.  The  government  contractually 
recognizes  certain  proprietary  rights  in  privately  developed  software.  The  DoD  regulations  do, 
however,  specifically  incorporate  copyright  law  in  some  respects,  and  also  seem  to  contemplate 
that  copyright  law  may  govern  as  to  some  things. 
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1.1  Ambiguities  or  Problems  in  the  Oats  Rights  Regulations  That  May  Harm 
the  Government’s  Interests 

There  are  several  provisions  in  the  current  DoD  FAR  SUPP  that  are  widely  perceived  to  be 
troublesome  for  the  government  in  achieving  some  of  the  goals  it  may  have  for  software  systems. 
Four  instances  of  this  are  discussed  in  this  section.  (Selected  portions  of  the  DoD  FAR  SUPP 
can  be  found  in  Appendix  B.) 


1.1.1  The  Apparent  Conflict  Between  the  Unlimited  Rights  Provision  and  the 
Retention  of  Copyright  Prevision 

It  is  standard  government  policy  to  obtain  unlimited  rights  in  any  software  developed  at  public 
expense  under  a  government  contract  or  subcontract  ( [61]  sec.  27.404-1).  "Unlimited  rights"  is 
defined  to  mean  "the  right  to  use,  duplicate,  or  disclose  ...  computer  software  in  whole  or  in  part, 
in  any  manner  and  for  any  purpose  whatsoever,  and  to  have  or  permit  others  to  do  so"  ( [61]  sec. 
27.401). 

Another  subsection  of  the  standard  policy  regulation  allows  contractors  to  retain  copyrights  in  all 
software  (or,  for  that  matter,  technical  data)  first  developed  or  generated  in  performance  of  a 
government  contract  even  if  funded  by  the  government  ( [61]  sec.  27.402(c)).  The  only  exception 
to  this  is  when  the  government  uses  its  "special  works"  clause,  which  purports  to  give  copyright 
ownership  to  the  government.  Where  a  contractor  owns  the  copyright,  the  government  is  sup¬ 
posed  to  get  a  license  back  to  copy  and  use  the  copyrighted  material  for  governmental  purposes 
( [61]  sec.  52.227-7013)  for  the  implementing  data  rights  clause;  see  also  [8]  (pp  487-488)  for  a 
discussion  of  this  ambiguity).  This  latter  provision  is  not  well  understood  by  DoD’s  own  procure¬ 
ment  personnel. 

It  is  possible  to  envision  a  scenario  where  the  government  might  expect  it  would  have  unlimited 
rights  in  software  developed  under  a  software  development  contract  only  to  find  that  the  contrac¬ 
tor  delivered  the  software  with  a  copyright  notice  on  it,  and  that  the  government’s  rights  would 
have  been  cut  back  because  of  the  contractor’s  invocation  of  the  copyright  protection.  Chapter  7 
gives  a  more  extended  hypothetical  discussion  of  how  this  might  conflict  with  the  government’s 
j  sense  of  its  interests. 

In  any  litigation  between  the  government  and  a  contractor  over  the  meaning  of  these  two  seem¬ 
ingly  conflicting  clauses,  it  seems  likely  that  a  court  would  construe  the  clauses  so  as  to  give 
effect  to  the  copyright  limitation.  The  law  generally  construes  any  ambiguity  in  a  contract  against 
the  party  -  here  the  government  --  that  has  drafted  it.  What  that  means  is  that  unlimited  rights 
’  doesn't  always  mean  unlimited  rights. 

I 

I 

|  In  fact,  it  may  never  mean  unlimited  rights.  Virtually  all  of  the  technical  data  and  software 

;  delivered  to  the  government  is  copyrightable  subject  matter.  Unpublished  copyrighted  subject 

>  matter  needn't  be  designated  with  a  copyright  notice  to  be  protected  under  that  law.  Because  of 

I  this,  it  may  be  that  unlimited  rights  never  means  anything  but  a  license  for  governmental  pur- 
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poses  (see  section  1.3.1).  DoD  personnel  need  to  understand  the  limitation  the  copyright  reten¬ 
tion  provision  may  impose  on  the  government’s  rights. 

The  current  regulations  should  be  revised  to  clarify  the  government’s  intention  as  to  the  copyright 
retention  provision.  Perhaps  the  government  needs  to  give  itself  an  unlimited  license  in 
copyrighted  material  funded  by  it,  or  perhaps  the  unlimited  rights  policy  should  be  modified  to 
make  it  dear  the  government  will  only  claim  rights  for  governmental  purposes.  The  government 
needs  to  make  a  choice,  and  then  to  clearly  communicate  the  direction  it  has  chosen. 

1.1  J2  The  Failure  to  Include  a  Right  to  Make  Derivative  Works  within  the  Definition 
of  Unlimited  Rights 

The  current  DoD  FAR  SUPP  definition  of  unlimited  rights,  both  in  the  policy  and  contract  dause 
provisions  of  the  procurement  regulations,  neglects  to  make  explicit  whether  the  government  will 
have  the  right  to  prepare  derivative  works  when  it  has  unlimited  rights  in  software  ( [61]  secs. 
27.401  and  52.227-7013(a)).  The  current  definition  speaks  only  of  rights  to  'use,"  "duplicate,’  and 
’disclose’  such  software.  Derivative  works  rights  are  particularly  important  as  to  software  be¬ 
cause  maintenance,  enhancement,  reuse,  translation,  rehosting,  and  retargeting  are  all  depend¬ 
ent  on  having  a  derivative  works  right.  (See  also  Chapter  4).  It  is,  of  course,  possible  that  a  court 
might  construe  the  existing  clause  to  include  a  derivative  works  right  notwithstanding  the  failure  to 
mention  this  important  right  in  the  definition,  but  it  would  seem  prudent  to  make  explicit  the 
government’s  claim  as  to  derivatives  if  indeed  this  is  as  significant  a  need  as  some  believe, 
especially  since  it  is  so  easy  to  do.  That  the  proposed  Federal  Acquisition  Regulations  explicitly 
define  unlimited  rights  to  include  a  derivative  works  right  weakens  DoD’s  argument  of  implicit 
inclusion. 

1.1.3  What  it  Might  and  Might  Not  Mean  to  Have  Unlimited  Rights  in  Non- 
deliverables 

The  government  claims  unlimited  rights  in  all  technical  data  and  software  developed  under  a 
government  contract  and  at  public  expense  ([61]  sec.  52.227-7013(b)(1)).  Often  a  government 
contract  will  call  for  delivery  of  only  certain  specified  items  of  technical  data  or  software.  Some¬ 
times  the  government  may  get  wind  of  some  valuable  intellectual  property  developed  under  the 
contract  (and  in  which  the  government,  therefore,  claims  unlimited  rights)  whose  delivery  has  not 
been  required  by  the  contract,  but  which  the  government  would  very  much  like  to  have.  The 
contractor  may  even  offer  to  "selP  this  valuable  thing  to  the  government.  Such  an  offer  is  likely  to 
be  rebuffed  by  government  lawyers  who  may  insist  that  ’it’s  already  ours.’ 

Although  the  regulations  do  seem  to  give  the  government  unlimited  rights  in  all  data  and  software 
generated  under  a  government  contract,  and  Professor  Nash  in  his  book,  Patents  and  Technical 
Data  ( [8])  speaks  of  the  government  having  an  "inchoate"  right  to  such  things  (pp.  450-51)  it  is 
difficult  to  know  what  it  means  to  claim  unlimited  rights  in  something  which  you  don’t  have  and 
which  the  person  who  has  it  is  under  no  enforceable  obligation  to  give  to  you. 


The  issue  could  arise  in  a  number  of  different  contexts.  For  example,  suppose  a  series  of  DoD 
contracts  was  awarded  to  a  small  business  over  a  several  year  period  for  development  of 
software.  Assume  the  contractor  developed  an  excellent  algorithm  that  was  not  a  deliverable  item 
under  the  contract,  and  offered  to  sell  it  to  the  government  for  an  additional  sum.  To  further  cloud 
the  issue,  suppose  there  had  been  a  short  hiatus  in  government  funding  of  the  research,  and  that 
it  was  during  this  hiatus  that  the  algorithm  was  developed  at  the  contractor's  expense.  The 
government  might  very  well  insist  that  the  contractor  deliver  the  algorithm  on  the  ground  that  it 
already  belonged  to  the  government.  The  contractor  would  I3rely  disagree,  creating  an  impasse. 
The  end  result  would  likely  be  that  the  government  would  have  to  meet  the  contractor’s  price,  or 
go  without  the  algorithm. 

There  would  be  some  equitable  pull  to  the  government's  argument  that  after  giving  this  small 
business  funding,  it  is  owed  something  of  value  in  return.  The  contractor’s  position  that  the  years 
of  government  funding  had  not  supported  development  of  this  product  might  appear  dubious  to 
some,  and  thus  could  weaken  the  contractor’s  equitable  argument.  Yet  there  would  also  seem  to 
be  some  equity  in  the  contractor's  stance.  He  could  argue  that  he  had  been  willing  to  deliver  what 
was  deliverable  under  the  contract,  and  it  wasn't  his  fault  that  the  government  hadn't  called  for 
delivery  of  the  algorithm  and  hadn't  put  in  a  deferred  ordering  clause  as  the  current  regulations 
allow.  Moreover,  since  the  government  would  not  have  had  a  contractual  basis  for  complaint 
against  the  contractor  had  he  not  developed  this  valuable  algorithm,  it  might  seem  to  some  as 
though  the  government  was  trying  to  get  something  for  nothing. 

Other  interesting  questions  deriving  from  the  problem  of  what  it  means  to  have  unlimited  rights  in 
non-deliverables  include:  whether  the  government  has  any  rights  if  the  contractor  later  sells  the 
valuable  non-deliverable  to  someone  else;  whether  the  government  can  rightfully  claim  unlimited 
rights  in  a  derivative  work  which  incorporates  the  non-deliverable  and  which  was  (but  for  the 
non-deliverable)  clearly  developed  at  private  expense;  and  what  if  any  obligation  the  contractor 
has  to  inform  the  government  of  any  other  use  of  the  non-deliverable.  If  a  contractor  has  reason 
to  believe  that  the  government  would  claim  unlimited  rights  in  a  derivative  of  non-deliverable 
software  if  that  item  is  later  delivered  under  a  subsequent  acquisition  arrangement,  the  contractor 
is  not  likely  to  be  willing  to  deliver  it. 

This  problem  seems  to  be  an  instance  of  confusion  over  the  meaning  of  "unlimited  rights"  vis-a- 
vis  ownership  (see  Section  1 .3)  as  well  as  another  instance  of  the  government’s  having  higher 
expectations  about  its  rights  than  "unlimited  rights’  seems  able  to  deliver.  The  advantage  to  DoD 
in  leaving  this  ambiguity  in  place  is  that  it  may  sometimes  be  helpful  in  negotiating  with  software 
developers  about  non-deliverable  software  or  algorithms.  The  disadvantage  to  DoD  in  leaving  this 
ambiguity  in  place  is  that  without  an  option  or  deferred  ordering  clause,  it  raises  expectations  that 
the  government  may  have  no  lawful  right  to  have  satisfied,  and  may  create  opportunities  for 
distrust  and  bitterness,  which  are  in  neither  the  government’s  nor  industry's  long  term  best  inter¬ 
est.  So,  it  would  be  wise  for  the  government  to  consider  making  the  deferred  ordering  clause 
standard,  or  drop  its  unlimited  rights  claims  to  non-deliverable  software  or  data. 


1 .1 .4  The  Apparent  Conflict  between  the  Special  Works  Clause  and  Section  1 05  of 
the  Copyright  Law 

The  policy  provisions  of  the  DoD  FAR  SUPP  advise  procurement  personnel  to  use  the  "special 
works"  clause  ( [61]  sec.  52.227-7020)  when  the  government  wants  to  exercise  ownership  and 
control  over  software  developed  at  public  expense  ( [61]  secs.  27.402  and  27.405).  Unfortunately, 
Section  105  of  the  Copyright  Act  of  1976(59]  (selected  portions  of  the  Copyright  law  can  be 
founded  in  Appendix  A)  expressly  prohibits  the  federal  government  from  owning  copyrights 
directly.  It  does,  however,  allow  the  government  to  take  copyrights  by  assignment,  bequest,  and 
the  like.  Trying  to  take  the  copyright  in  software  as  if  it  is  a  "work  made  for  hire*  (as  the  special 
works  clause  purports  to  do)  does  not  seem  to  be  a  taking  by  assignment  or  bequest.  (See 
Chapter  5.) 

Section  105  of  the  copyright  law  may,  therefore,  have  the  effect  of  nullifying  the  "special  works" 
clause  ( [61]  sec.  27.405)  and  the  implementing  clause  ( [61]  sec.  52.227-7020)  insofar  as  they 
purport  to  give  the  government  a  direct  copyright  interest  in  works  prepared  for  it  by  private 
contractors.  DoD  does  not  by  regulation  have  the  power  to  nullify  statutes,  so  if  there's  a  conflict, 
it  is  the  DoD  regulation  that  must  yield.  (We  have  been  informed  that  the  DoD's  special  works 
clause  has  been  used  in  many  development  contracts  for  software.  This  raises  the  specter  that 
any  software  in  which  the  government  claims  direct  copyright  interest  through  the  special  works 
clause  will  be  held  to  be  in  the  public  domain). 

If  DoD  wants  to  own  copyrights  in  certain  software,  it  may  want  to  consider  adopting  an  approach 
similar  to  that  which  NASA  or  the  newly  proposed  FAR  regulations  have  taken,  which  allows  the 
government  to  require  the  contractor  to  obtain  a  copyright  in  the  software  developed  at  govern¬ 
ment  expense  and  assign  it  back  to  the  government.  (See  Chapter  5.) 

1 .2  Ambiguities  or  Problems  in  the  Regulations  That  May  Harm  Industry’s 
Interests 

Just  as  there  are  several  provisions  of  the  current  DoD  regulations  that  seem  to  offer  the  govern¬ 
ment  lesser  rights  than  it  might  have  expected  it  had,  there  are  several  provisions  that  suggest 
that  even  when  software  and  its  associated  documentation  have  been  developed  wholly  at 
private  expense,  unwary  contractors  may  find  the  government  claiming  unlimited  rights  in  these 
materials  rather  than  the  more  restrictive  rights  the  contractor  might  have  expected.  Two  in¬ 
stances  of  this  type  of  problem  are  discussed  in  this  section. 

1.2.1  Getting  Unlimited  Rights  in  Privately  Developed  Software  Seemingly  Subject 
to  Restricted  Rights  as  to  Which  a  Separate  License  Agreement  Has  Not 
Been  Incorporated  Into  the  Contract 

The  DoD  standard  data  rights  clause  ( [61]  sec.  52-227.7013(b)(3))  distinguishes  between  two 
types  of  restricted  rights,  those  applicable  to  commercial  software  and  those  applicable  to  other 
software.  As  to  the  former,  there  is  a  standard  set  of  restrictions  on  the  government’s  use.  As  to 


the  latter,  it  is  clearly  contemplated  that  other  restrictions  can  be  negotiated  by  the  parties,  sub¬ 
ject  only  to  the  requirement  that  the  government  always  has  the  lour  minimum  rights  set  torth  in 
the  clause.  (A  different  restrictive  legend  is  to  be  attached  to  the  software  depending  on  which 
arrangement  the  contractor  has  elected  to  take.)  The  language  of  the  standard  clause  con¬ 
templates  that  a  separate  license  agreement  containing  other  restrictions  is  to  be  negotiated  and 
made  a  part  of  the  government  contract. 

The  issue  arises:  what  happens  if  a  separate  license  agreement  has  not  been  negotiated,  or  if  a 
license  agreement  has  been  negotiated  but  not  explicitly  made  part  of  the  government  contract? 
Reportedly,  many  firms  have  provided  their  proprietary  software  to  DoD,  and  have  not  negotiated 
separate  licensing  agreements,  let  alone  made  such  agreements  part  of  the  government  con¬ 
tracts.  These  software  firms  apparently  assume  that  the  government  will  have  no  more  than  the 
four  minimum  rights. 

The  government  might  make  the  argument  that  unless  there  is  a  separate  agreement  and  it  is 
made  a  part  of  the  government  contract,  the  government  has  unlimited  rights  in  the  software.  The 
following  language  of  the  clause  could  be  used  to  support  this  interpretation:  The  contractor  may 
not  place  any  legend  on  computer  software  indicating  restrictions  on  the  Government's  rights  in 
such  software  unless  the  restrictions  are  set  forth  in  a  license  or  agreement  made  a  part  of  this 
contract  prior  to  the  delivery  date  of  the  software."  On  the  other  hand,  industry  might  argue  that 
the  government  should  be  held  to  the  four  minimum  rights  where  no  separate  license  was 
negotiated  or  made  part  of  the  contract,  so  long  as  the  software  was  developed  wholly  at  private 
expense. 

If  the  government  did  decide  to  litigate  on  a  claim  of  unlimited  rights  in  software  where  no 
separate  agreement  was  made  part  of  the  contract,  we  think  it  unlikely  that  a  court  would  uphold 
the  government's  interpretation  of  this  clause.  If  a  software  firm  provided  the  government  with  its 
proprietary  software  on  the  understanding  and  in  the  expectation  that  no  more  than  the  four 
minimum  rights  would  have  attached,  it  would  seem  likely  that  the  court  would  protect  the  party's 
reasonable  expectations.  Modem  contract  law  has  moved  away  from  hyper-technical  approaches 
to  contract  formation  and  tends  to  enforce  reasonable  expectations  of  the  parties.  This  is  a  case, 
however,  in  which  even  if  the  government  won,  it  could  lose  in  the  long  run  since  the  mere 
pressing  of  the  claim  might  further  impair  already  strained  relations  between  industry  and  govern¬ 
ment. 

Some  industry  people  who  knew  about  this  little  "booby  trap"  in  the  regulations  were  nervous 
about  it,  but  thought  that  DoD’s  contracting  personnel  would  be  "reasonable"  and  not  spring  the 
trap.  Even  where  the  likelihood  of  harm  may  be  perceived  to  be  slight,  however,  a  software 
contractor  may  be  unwilling  to  take  even  the  risk  presented  by  the  DoD  procurement  regulations 
when  the  firm’s  most  valuable  technology  would  be  at  stake.  This  disincentive  to  do  business  with 
the  DoD  is  even  more  pronounced  where  a  small  contractor  is  involved  since  the  valuable  tech¬ 
nology  at  issue  is  likely  to  be  the  very  "lifeblood"  of  the  company,  that  is,  the  competitive  edge 
which  allows  the  company  to  survive  in  the  marketplace.  In  such  cases,  even  a  slight  risk  is  likely 
to  dissuade  such  a  company  from  doing  business  with  the  DoD,  with  the  result  that  useful  tech- 
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nological  innovations  will  be  unavailable  to  DoO.  For  this  reason,  it  would  be  wise  to  revamp  the 
DoD  procurement  regulations  so  as  to  avoid  such  “booby  traps." 
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1.2.2  Getting  Unlimited  Rights  In  Software  Documentation  as  to  Other  Than 
Commercial  Software 

Software  documentation  is  often  included  in  manuals.  It  may  also  be  characterized  as  instruc¬ 
tional  material  necessary  to  maintain  a  system.  Manuals  and  instructional  material  necessary  to 
maintain  a  system,  which  are  required  to  be  delivered  under  a  government  contract,  are  materials 
in  which  the  government,  through  the  standard  data  rights  clause  ([61]  sec. 
52.227-701 3(b)(1)(vii))  claims  unlimited  rights  even  if  it  has  been  developed  at  private  expense. 
Since  virtually  all  software  documentation  may  be  construed  to  be  within  the  clause,  potentially  all 
software  documentation  may  be  subject  to  unlimited  rights  claims.  Since  software  documentation 
tends  to  be  particularly  sensitive  commercial  information,  this  creates  a  prospect  for  considerable 
loss  if  a  company  provides  documentation  to  DoD. 

If  the  documentation  pertains  to  commercial  software,  it  might  arguably  be  exempted  from  the 
broad  reach  of  the  unlimited  rights  provision  because  the  commercial  software  restricted  rights 
provision  ( [61]  sec.  52.227-701 3(b)(3)(ii))  indicates  that  not  only  the  machine-readable  code  but 
any  related  software  documentation  that  has  been  developed  at  private  expense  and  is  not  in  the 
public  domain  will  be  subject  to  restricted  rights.  If  the  documentation  pertains  to  non-commercial 
software,  there  is  no  comparable  basis  for  claiming  an  exemption  under  the  other  restricted  rights 
provision,  ( [61]  sec.  52.227-701 3(b)(3)(i)).  Some  DoD  people  think  this  means  that  the  govern¬ 
ment  will  have  unlimited  rights  to  other  than  commercial  software  documentation,  even  though  it 
was  developed  at  private  expense  and  is  not  in  the  public  domain. 

Like  the  previously  described  example,  this  "booby  trap*  requires  a  highly  technical  reading  of  a 
very  complicated  and  long  (nine  page)  clause.  Like  the  other  example,  the  incongruity  is  not 
obviously  flagged  so  that  a  diligent  industry  person  who  read  the  clause  would  understand  what 
he  or  she  was  giving  up.  Like  the  other  incongruity,  it  is  most  likely  the  result  of  imprecise  drafting 
rather  than  being  an  intentional  statement  of  clearty  articulated  policy.  It  would  make  no  sense  to 
interpret  the  clause  as  subjecting  the  machine-readable  code  to  the  restricted  rights  provision  and 
yet  to  treat  the  documentation  (which  would  likely  contain  all  the  most  sensitive,  commercially 
valuable  information)  as  if  the  government  had  unlimited  rights  in  it  and  could  show  it  to 
whomever  it  wished.  Again,  even  if  the  government  chose  to  litigate  the  issue  and  won,  it  would 
stand  to  lose  credibility  because  of  the  perceived  unfairness  of  such  a  position. 

It  should  also  be  noted  that  the  DoD  procurement  regulations  do  not  clearly  distinguish  commer¬ 
cial  software  from  other  than  commercial  software.  According  to  the  regulations,  software  is 
commercial  if  it  is  "used  regularly  for  other  than  government  purposes  and  is  sold,  licensed  or 
leased  in  significant  quantities  to  the  general  public  at  established  market  or  catalog  prices"  ( [61] 
sec.  27.401).  It  seems  that  as  much  as  55%  non-government  sales  and  use  might  be  required  in 
order  for  software  to  qualify  for  treatment  as  commercial  software  ([8]  pp  501).  The  precise 
dividing  line,  however,  is  unclear.  It  should  also  be  noted  that  software  which  is  developed  for  the 
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government  with  an  intention  that  it  also  be  sold  in  the  commercial  marketplace  wifi  not  likely 
qualify  for  treatment  ai  commercial  software  since  at  the  time  of  development  there  will  be  no 
sales  outside  of  the  government.  Our  understanding  is  that  because  of  the  ambiguities  of  lan¬ 
guage  in  the  regulations,  most  contractors  do  not  exercise  the  option  of  having  software  treated 
as  commercial. 


1.3  The  Need  for  More  Precise  Definitions 

1.3.1  What  Unlimited  Rights  Means  Vls-a-Vis  Ownership 

There  does  not  seem  to  be  a  consensus  among  DoD  personnel  about  what  'unlimited  rights' 
means  vis-a-vis  ownership.  We  discovered  at  least  four  interpretations  DoD  personnel  had  as  to 
this  issue. 

(a)  Some  think  it  is  the  equivalent  of  ownership. 

As  one  person  has  said,  'if  it  looks  like  a  duck  and  quacks  like  a  duck,  it  is  a  duck.' 

(b)  Some  think  it  means  the  government  co-owns  the  subject  matter,  the  government  owning  it 
in  the  governmental  sphere,  the  contractor  owning  it  in  the  commercial  sphere. 

The  recoupment  provision  was  thought  by  some  to  support  this  interpretation. 

(c)  Some  think  it  means  the  thing  is  ]n  the  public  domain. 

Certainly,  with  trade  secret  data,  what  the  government  seems  to  have  is  the  capability  to  put  the 
thing  in  the  public  domain. 

(d)  Some  think  it  means  that  the  the  contractor  owns  the  thing  and  that  the  government  has  a 
license  back  to  use  the  thing  for  governmental  purposes. 

Section  1 .1 .1  suggests  that  this  last  interpretation  may  be  the  more  appropriate  one.  Yet  there  is 
a  big  difference  between  'unlimited  rights’  as  defined  by  section  27.401  (to  use.  duplicate  or 
disclose ...  jn  any  manner  and  for  any  purpose  whatsoever,  and  to ...  permit  others  to  do  so*)  and 
'license  rights*  as  defined  by  that  same  section  (which  limits  the  right  to  use,  duplicate  or  disclose 
to  'governmental  purposes”),  so  something  different  must  have  originally  been  meant  by  un¬ 
limited  rights. 

Why  does  it  make  a  difference  what  it  means?  Because  DoD  people  (and  industry  people  as  well) 
sometimes  think  of  'unlimited  rights'  as  an  ownership  interest  which  means  they  may  act  on  this 
belief,  which  means  they  can  get  into  trouble  if  it  isn’t  true.  For  example,  in  negotiating  a  software 
development  contract  as  to  which  keeping  control  over  derivative  software  may  be  important,  the 
government  may  use  the  standard  data  rights  clause  and  expect  to  get  unlimited  rights.  The 
government  might  have  thought  it  wouldnl  need  a  copyright  since  it  would  have  unlimited  rights 
or  it  might  think  unlimited  rights  was  ownership.  But  if  the  contractor  copyrights  the  software,  the 
government  may  not  have  unlimited  rights;  and  even  if  it  has  unlimited  rights  as  to  uncopyrighted 
software,  it  isn’t  clear  this  includes  rights  to  make  derivative  software.  (See  Chapter  7.)  What 
unlimited  rights  really  means  vis-a-vis  ownership  matters. 
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The  way  intellectual  properly  law  tends  to  define  "ownership*  and  "property  rights"  is  not  so  much 
in  terms  of  what  a  particular  person  can  do  with  a  particular  thing,  but  in  terms  of  what  right  he  or 
she  has  to  exclude  other  people  from  doing  things  with  that  property.  (Patent  law,  for  example, 
gives  the  patentee  the  right  to  exclude  others  from  making,  using,  or  selling  the  patented  inven¬ 
tion  for  seventeen  years  ( [65],  sec.  154).  The  government’s  "unlimited  rights"  definition  seems  to 
go  to  what  the  government  can  do  with  software  and  its  documentation  and  what  it  can  authorize 
others  to  do,  and  does  not  grant  any  rights  to  the  government  to  exclude  others  from  it.  For  this 
reason,  intellectual  property  law  would  likely  treat  "unlimited  rights"  as  a  broad  license,  not  as  an 
ownership  interest  (e.g.,  Regents  of  the  University  of  Colorado  v.  K.D.I.  Precision  Products,  Inc., 
[43],  discussing  the  difference  between  "unlimited"  and  "exclusive"  rights). 

1.3.2  Governmental  Purpose 

If  all  "unlimited  rights’  truly  means  is  a  license  to  use  "for  governmental  purposes,"  it  is  important 
to  understand  what  the  latter  term  means.  Unfortunately,  the  DoD  FAR  SUPP  does  not  define 
the  term  at  all.  Does  it  mean: 

a)  for  use  by  all  federal  governmental  agencies,  or  only  by  DoD,  or  only  by  the  particular  service 
that  obtained  the  rights?  If  the  former,  does  that  mean  NASA  can  get  it  for  nothing  just  for  the 
asking? 

b)  for  use  by  state  or  local  governments  if  the  OoD  thinks  it  a  good  idea  to  share  the  software? 

c)  for  use  by  foreign  governments  to  whom  the  U.S.  government  wants  to  give  it? 

d)  for  use  in  the  defense  community  as  a  whole  (including  all  private  firms  who  contract  with 
DoD)  if  DoD  thinks  it  is  a  good  idea  to  share  the  thing? 

e)  for  use  by  defense  contractors  in  foreign  countries  to  whom  the  government  might  want  to 
give  the  software? 

f)  for  use  to  enable  the  government  to  get  something  at  a  low  cost  or  for  free?  (See  Chapter  7). 

g)  for  use  in  competitive  reprocurements  or  maintenance  contracts? 

Because  of  Congress'  recent  intense  concern  about  competitive  reprocurements,  the  last  of  these 
questions  may  seem  to  be  of  the  greatest  topical  interest,  but  all  of  these  questions  are  of  con¬ 
siderable  importance.  Prior  case  law  would  seem  to  take  a  narrow  view  of  the  term’s  meaning 
([8]  pp  425-426). 

1.3.3  Privately  Developed  Software 

Because  so  much  of  DoD’s  policy  on  the  allocation  of  rights  turns  on  whether  software  was 
developed  at  private  or  public  expense,  it  would  be  highly  desirable  to  define  this  term  in  the 
regulations,  and  to  make  its  definition  part  of  one  of  the  standard  clauses  required  to  be  placed  in 
all  development  contracts.  In  this,  we  concur  with  the  earlier  conclusion  of  the  OSD  Technical 
Data  Rights  Study  [11].  That  Study’s  definition  ("developed  without  direct  payment  by  the  govern¬ 
ment  which  requires  the  performance  of  the  developmental  effort")  is  a  step  in  the  right  direction, 
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although  it  still  does  not  address  the  critical  issue  of  what  it  means  for  software  or  technical  data 
to  be  "developed''  (i.e.,  what  are  the  critical  events,  especially  as  to  software  --  When  the  algo¬ 
rithm  is  developed?  When  the  source  code  is  written?  When  the  code  is  first  compiled?  When  it  is 
debugged?  etc). 

The  proposed  revisions  to  the  DoD  FAR  SUPP  data  rights  provisions  issued  in  the  late  summer 
of  1985  undertook  to  define  "developed"  and  "developed  at  private  expense"  more  precisely. 
Unfortunately,  the  definition  proposed  is  so  stringent  that  virtually  no  software  would  qualify  as 
privately  developed  software  (because  of  the  testing  requirement  and  because  of  the  requirement 
that  a]l  development  be  completed  before  any  government  contract  for  the  software  is  in 
existence).  The  proposed  definition  (like  another  similar  attempt  a  few  years  ago)  has  proved  too 
controversial  to  be  adopted  ( [8]  pp  443-445).  It  does  seem  time  to  try  to  develop  a  definition  that 
both  industry  and  government  can  live  with.  The  term  is  too  important  not  to  be  defined. 
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1.3.4  Two  Types  of  Restricted  Rights 

The  policy  provisions  of  the  DoD  FAR  SUPP  ((61]  sec.  27.401)  contain  only  one  definition  of 
restricted  rights  applicable  to  software.  The  implementing  data  rights  clause  found  at  ( [61]  sec. 
52.227-7013)  sets  forth,  in  subsections  (b)(3)(f)  and  (ii),  two  different  sets  of  restricted  rights,  one 
applicable  to  commercial  software  (at  the  vendor's  election)  and  one  applicable  to  other  software. 

One  of  the  problems  with  this  approach  is  that  while  the  two  sets  of  rights  resemble  each  other  in 
some  respects,  they  are  not  the  same,  and  to  the  extent  they  are  different,  it  is  not  apparent  what 
principled  basis  exists  for  the  differentiation.  (One,  for  example,  focuses  on  the  computer  for 
which  software  was  acquired,  whereas  the  other  focuses  on  the  facility.  Also,  the  two  sets  of 
rights  do  not  seem  to  treat  modifications  the  same.)  It  appears  that  the  differences  may  be  the 
result  of  imprecise  drafting.  If  these  differences  are  intentional,  then  they  should  be  explained. 

Another  problem  is  that  there  isn’t  an  easy  way  to  refer  to  the  two  kinds  of  restricted  rights.  That 
is,  it  would,  at  a  minimum,  be  helpful  to  be  able  to  refer  to  "commercial  software  restricted  rights" 
and  "trade  secret  software  restricted  rights."  It  is  also  hard  to  comprehend  why  documentation 
concerning  commercial  software  should  be  allowed  to  get  restricted  rights  treatment,  but  not 
documentation  for  other  software.  Subjecting  other  than  commercial  software  documentation  to 
the  broader  "limited  rights"  policy  (giving  the  government  the  right  to  use,  disclose  and  duplicate 
the  documentation  throughout  the  government)  has  an  added  disadvantage  for  the  government  in 
that  it  deters  many  software  firms  from  doing  business  with  DoD  or  from  selling  rights  to  their 
most  valuable  technologies.  Moreover,  none  of  the  contract  officers  to  whom  we  spoke  could  tell 
us  the  difference  between  these  two  sets  of  restricted  rights  or  could  tell  us  how  to  apply  them. 
Industry  people  also  seemed  somewhat  confused  by  these  two  sets  of  rights.  This  creates  need¬ 
less  confusion. 
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What  seems  to  be  the  general  intent  of  this  segment  of  the  regulations  is  to  set  a  “floor"  of  £ 

minimum  rights  which  the  government  must  always  have  (as  well  as  setting  a  standard  "ceiling”  ■ 

of  unlimited  rights  when  government  funding  has  been  used)  and  then  to  indicate  that  inter- 
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mediate  arrangements  between  the  "floor''  and  "ceiling"  may  be  appropriate,  depending  on 
governmental  needs.  If  that  is  the  intent,  there  are  simpler  ways  to  say  this  than  the  current  DoD 
regulations  do. 

1.3.5  Distinguishing  Types  of  Documentation 

The  definitions  to  the  procurement  regulations  do  not  differentiate  at  all  among  the  various  types 
of  software  documentation.  Some  documentation  contains  sensitive  information,  and  hence,  is 
jealously  guarded  by  the  developer.  For  example,  documentation  which  reveals  internal  design 
information,  algorithms,  and  proprietary  information  of  a  program  may  need  to  be  distinguished 
from  training  and  user  manuals.  Industry  may  be  willing  to  accept  a  broader  rights  package  as  to 
the  latter  types  of  documentation.  However,  unless  a  more  restrictive  rights  package  is  available 
as  to  the  former,  the  company  may  choose  not  to  do  business  with  DoD,  or  may  sell  only  "old" 
technology  to  DoD.  DoD’s  policy  should  reflect  these  concerns  by  distinguishing  forms  of 
documentation  in  such  a  way  that  differential  rights  treatment  can  be  effected. 

1.4  Issues  Not  Addressed  In  the  DoD  Regulations 

1.4.1  CAD/CAM  Programs 

An  issue  frequently  raised  by  DoD  procurement  personnel  in  our  interviews  was  how  to  fit 
computer-aided  design/computer-aided  manufacturing  (CAD/CAM)  programs  into  the  regulatory 
structure  for  DoD  procurements.  A  separate  chapter  (Chapter  10)  discusses  the  CAD/CAM 
issues  at  greater  length.  The  primary  reason  CAD/CAM  programs  seem  difficult  to  fit  into  the  DoD 
FAR  SUPP  structure  is  that  the  structure  assumes  that  the  government  will  obtain  a  physical  copy 
of  any  proprietary  software  which  it  chooses  to  acquire.  If  the  government  gets  a  physical  copy,  it 
will  get  at  least  the  four  minimum  rights  in  the  software  that  are  set  forth  in  the  regulations. 

Purveyors  of  CAD/CAM  programs  have  sometimes  been  willing  only  to  license  certain  access  to 
their  CAD/CAM  programs,  and  not  to  allow  the  government  to  get  a  copy  of  the  program  itself  and 
not  to  get  the  standard  set  of  minimum  rights  to  the  software.  A  second  important  facet  of  the 
CAD/CAM  dilemma  is  that  manufacturers  of  major  systems  for  the  government  who  use 
CAD/CAM  programs  may  be  much  less  willing  to  deliver  large  volumes  of  technical  data  about 
the  system,  arguing  instead  that  the  government’s  needs  can  be  met  by  controlled  access  to  the 
manufacturer’s  CAD/CAM  program.  This  may  make  the  government  more  dependent  on  firms 
using  CAD/CAM  programs  when  seeking  competitive  reprocurements.  The  present  regulations 
do  not  provide  guidance  about  how  to  deal  with  this  situation. 

1.4.2  Local  Area  Networks 

It  is  becoming  more  common  for  units  within  the  Defense  Department  to  establish  local  area 
networks  which  share  software.  The  DoD  procurement  regulations  do  not  provide  guidance  about 
making  acquisitions  of  software  intended  for  use  in  network  environments.  NASA  regulations  do 
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make  provisions  to  accommodate  this  technological  development  ([64],  sec.  18-27.473-2(e)). 
The  DoO  should  think  about  doing  so  as  well. 


1.4.3  "Time  Bombs,"  "Worms,"  and  "Triggers" 

Some  software  being  sold  commercially  contains  "time  bombs,”  software  devices  that  at  a 
prescribed  time  either  stop  the  software  from  working  or  stop  it  from  working  accurately.  Other 
software  contains  "worms,”  software  devices  that,  upon  a  certain  condition  being  met,  cause 
destruction  to  that  software,  other  software,  or  stored  data.  Still  other  software  contains  "triggers,” 
software  devices  which  prevent  software  from  running  on  any  but  a  specifically  identified  C.P.U. 
Because  of  the  possibility  that  a  software  firm  might  install  time  bombs’  or  "worms”  or  triggers” 
in  software  acquired  by  the  government,  perhaps  the  regulations  ought  at  least  to  require  notice 
to  the  government  if  software  is  to  be  delivered  with  time  bombs'  or  other  such  devices. 


1.4.4  The  New  Chip  Law 

The  only  forms  of  intellectual  property  law  to  which  the  OoD  FAR  SUPP  makes  reference  are 
patent  and  copyright  law.  In  fall  of  1984,  Congress  created  a  new  form  of  intellectual  property  law 
to  protect  designs  of  semiconductor  chips.  Because  much  of  the  software  that  OoD  buys  is 
delivered  on  chips,  the  new  chip  law  seems  at  least  somewhat  related  to  DoD’s  software  licens¬ 
ing  practices,  and  hence  within  the  broad  scope  of  this  report.  Chapter  12  discusses  the  features 
of  the  chip  law  as  they  may  affect  the  Defense  Department. 

1.4.5  Trademarks 

Another  form  of  intellectual  property  law  to  which  the  DoD  FAR  SUPP  makes  no  reference  is 
trademark  law.  Because  it  is  becoming  more  common  for  the  government  to  take  trademark 
rights  as  to  software  under  development  (especially  in  connection  with  the  government’s  promo¬ 
tion  of  Ada  as  a  standard  language  for  military  applications),  some  standard  clauses  for  obtaining 
trademark  rights  in  software  products  produced  for  the  government  by  private  firms  should  be 
available.  Because  of  some  nonobvious  wrinkles  in  the  trademark  law  which  could  trip  up  the 
government's  efforts  to  maintain  trademark  rights,  explained  at  some  length  in  Chapter  6,  it  is 
important  to  have  a  policy  which  will  get  it  right  the  first  time. 

1.4.6  Government  Rights  in  Derivative  Works 

As  Chapter  4  explains  at  greater  length,  there  are  a  number  of  'derivative  works*  issues  not 
currently  addressed  by  the  current  regulations  which  are  of  some  considerable  importance  in 
software  acquisitions.  Two  of  the  issues  are:  (a)  what  if  any  rights  the  government  has  in 
contractor-prepared  derivative  works  of  software  in  which  the  government  claims  unlimited  rights 
(see  also  Chapter  7)  and,  (b)  what  if  any  rights  the  government  has  in  modifications  it  makes  to 
restricted  rights  software  prepared  either  by  it,  or  for  it  by  private  firms. 
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1.4.7  Software  Warranties 


A  number  of  people  raised  the  issue  of  what  if  any  warranties  the  government  can  or  should  get 
in  software.  Those  persons  pointed  out  that  there  are  provisions  in  the  DoD  FAR  SUPP  ( [61] 
specifically  sections  27.410-5  and  52.246-7001)  regarding  warranties  for  technical  data.  Because 
software  is  a  developing  art,  it  may  be  difficult  to  obtain  warranties  for  it,  but  numerous  people 
have  indicated  a  desire  for  a  policy  about  software  warranties.  Whether,  in  the  absence  of  any 
contractual  provision  concerning  warranties,  the  government  may  claim  implied  warranties  (e.g., 
of  merchantability  or  fitness  for  a  particular  purpose)  have  attached  to  delivered  software  is  ad¬ 
dressed  in  Chapter  11).  If  getting  more  explicit  standard  warranties  for  software  is  desired,  some 
regulatory  guidance  might  be  helpful  to  procurement  personnel. 

1.4.8  "Shrink  Wrap"  Licenses 

Much  of  the  commercial  software  presently  available  in  the  market  comes  with  what  purports  to 
be  a  "licensing  agreement"  either  inside  the  box  or  just  under  the  plastic  wrapping  (commonly 
known  as  "shrink  wrap"  licenses).  Typically  these  forms  provide  that  by  opening  the  box  or  the 
plastic  wrapping,  one  will  be  presumed  (by  the  software  vendor,  if  not  by  the  law)  to  have  con¬ 
sented  to  a  series  of  restrictions  on  use  of  the  software,  as  well  as  to  have  accepted  that  one  is 
not  really  the  owner  of  a  copy  of  the  software,  but  only  a  licensee  of  the  manufacturer,  and  to 
have  agreed  to  respect  the  manufacturer's  trade  secrets  and  other  proprietary  rights  in  the 
software,  and  to  have  consented  to  a  variety  of  other  matters  (e.g.,  what  state  law  will  apply  in  a 
dispute).  When  the  government  buys  this  kind  of  software,  the  question  is  whether  these  licenses 
bind  the  government.  This  question  was  raised  time  and  again  in  our  interviews  with  DoD  person¬ 
nel. 

One  view  within  DoD  is  that  the  procurement  regulations  (and  in  particular  the  standard  data 
rights  clause)  would  be  given  legal  effect,  even  if  not  explicitly  incorporated  into  the  contract. 
Others  thought  that  perhaps  the  shrink  wrap  licenses  might  be  viewed  as  modifying  (and 
controlling)  the  standard  clause,  or  that  the  absence  of  the  basic  data  rights  clause  in  the  pur¬ 
chase  arrangement  might  mean  it  would  not  govern.  Because  a  raft  of  questions  about  shrink 
wraps  Often  come  up,  it  is  worth  going  into  them  in  somewhat  more  detail,  as  the  next  subsection 
does. 

1.5  Shrink  Wrap  and  Other  Standard  Licenses 

The  first  three  subsections  deal  with  a  set  of  questions  which  were  posed  to  us  about  shrink  wrap 
licenses.  The  last  several  subsections  deal  with  questions  which  DoD  might  want  to  ask. 

1.5.1  Authority  to  Bind 

By  far  the  most  commonly  asked  question  about  these  licenses  was  who  was  supposed  to  open 
the  package  to  validate  them  (or  who  is  to  sign  in  the  case  of  other  standard  licensing 
arrangements).  It  was  widely  thought  that  unless  the  contract  officer  broke  open  the  package  or 


signed  the  agreement,  the  government  could  not  be  bound  by  the  terms  of  the  license  because 
only  the  contract  officer  has  the  power  to  bind  the  government.  Yet  companies  widely  insisted  on 
getting  the  actual  user  either  to  sign  or  to  break  open  the  package.  Those  who  believed  that  such 
acts  by  users  would  not  bind  the  government  also  believed  that  if  users  opened  the  package  or 
signed,  they  would  expose  themselves  to  personal  liability  and  potentially  to  injunctive  relief  (even 
if  acting  in  a  governmental  capacity),  which  was  thought  to  be  undesirable  and  perhaps  incon¬ 
sistent  with  the  regulatory  mandate.  It  would  be  very  helpful  to  the  people  who  have  to  use  these 
regulations  for  procuring  software  to  be  able  to  get  clear  guidance  from  the  regulations  about  this 
troublesome  issue. 

1.5.2  What  Effect  on  Government's  Rights 

What  effect  the  failure  of  the  contract  officer  to  open  the  package  or  sign  the  agreement  would 
have  on  the  extent  of  the  government's  rights  thereafter  was  also  a  subject  of  some  debate. 
Would  it  be  unlimited  rights  because  of  the  failure  to  follow  proper  procedures  and  to  make  the 
restrictions  a  part  of  the  government  contract?  Or  restricted  rights  normally  applicable  to  commer¬ 
cial  software?  Since  these  licenses  typically  restrict  the  government's  ability  to  modify  the 
software,  they  contain  less  than  the  four  minimum  rights  the  procurement  regulations  say  the 
government  must  have.  How  that  affects  the  government's  rights  also  mystified  some,  although 
others  pointed  out  that  ( [61],  sec.  27.404-1  (c))  states  that  "[a]s  a  minimum,  however,  the  Govern¬ 
ment  shall  have  the  rights  provided  in  the  definition  of  restricted  rights  in  Section  27.401,"  and 
that  the  Christian  Associates  case  [29]  suggests  that  clauses  that  are  mandatory  in  government 
contracts  will  be  read  into  a  contract  even  if  not  found  there.  (That  case  involved  a  contract  silent 
on  a  clause,  not  one  contradicting  the  clause.)  (See  Chapter  8  for  more  discussion  of  this 
problem.) 

1.5.3  Other  Terms  in  Violation  of  Federal  Procurement  Regulations 

Many  of  the  other  standard  terms  of  these  licenses  are  in  conflict  with  federal  procurement  law. 
For  example,  they  typically  set  forth  such  things  as  what  state  law  will  govern  disputes,  and 
where  lawsuits  are  to  be  brought,  as  well  as  providing  for  instant  termination  of  the  license  in  the 
event  of  any  violation  of  the  terms  of  the  license,  and  a  return  of  the  software  to  the  vendor.  The 
government  could  be  expected  to  argue  that  none  of  these  would  bind  the  government  even  if  the 
contract  officer  broke  open  the  package  or  signed  the  license  agreement.  Since  the  contract 
officer  is  not  authorized  to  agree  to  things  which  are  in  violation  of  the  procurement  regulations, 
the  argument  would  conclude  that  the  government  would  not  be  bound  by  these  conditions.  That 
may  well  be  so,  but  what  would  be  helpful  to  the  people  in  the  field  is  to  have  a  regulation  that 
explicitly  addresses  this  problem. 


1.5.4  Are  These  "Licenses"  Enforceable? 

A  question  which  should  be  asked  is  whether  these  shrink  wrap  licenses  have  any  legal  effect 
whatever.  Although  the  States  of  Louisiana  and  Illinois  have  passed  laws  recognizing  their 
validity,  there  are  many  who  regard  these  ’shrink  wrap*  licenses  as  unenforceable  as  a  matter  of 
contract  law,  imposing,  as  they  attempt  to  do,  restrictions  on  the  purchaser’s  rights  after  the 
contract  has  been  made,  and  relying,  as  they  do,  on  opening  a  package  or  box  as  indicative  of 
consent  when  it  may  easily  be  indicative  of  disregard. 

Others  question  the  legality  of  certain  provisions  of  shrink  wrap  licenses  under  the  copyright  law 
because  the  licenses  purport  to  control  uses  that  can  be  made  of  the  software.  Copyright  law 
does  not  give  copyright  owners  any  rights  to  control  use.  These  'licenses*  also  purport  to  deprive 
purchasers  of  rights  they  would  be  emitted  to  as  "owners*  of  a  copy  of  software,  such  as  the  right 
to  resell  the  copy  and  the  right  to  make  a  "backup*  copy. 

1.5.5  NASA’s  Special  Data  Rights  Clause 

To  give  clear  guidance  to  NASA  personnel  who  are  responsible  for  procuring  commercial 
software,  NASA  has  adopted  a  regulation  to  clarify  that  the  government’s  data  rights  under  the 
original  sales  contract  will  not  be  superceded  by  delivery  documents  containing  inconsistent  data 
rights  provisions  ( [64]  sec.  1827.473-4(b)(2)  and  1852.227-79).  In  essence,  what  that  clause 
says  is  "notwithstanding  anything  that  might  be  construed  to  the  contrary,  the  government  always 
gets  the  following  minimum  rights  and  government  procurement  regulations  govern  if  there  are 
any  other  seemingly  inconsistent  terms.*  In  effect,  this  clears  up  all  the  problems  described  in  the 
first  three  subsections  above. 

1.5.6  "Published"  Commercial  Software 

One  other  part  of  the  same  NASA  regulation  which  DoD  might  warn  to  consider  adopting  is  that 
which  "lifts*  the  restriction  on  the  government's  right  to  disclose  copyrighted  software  that  has 
been  "published"  (widely  distributed  with  a  copyright  notice)  within  the  meaning  of  the  copyright 
law.  If  copyrighted  material  has  been  ’published,"  the  ideas  and  information  it  oontains  are  con¬ 
sidered  to  be  in  the  public  domain,  which  should  mean  that  restrictions  on  disclosure  should 
cease.  Whether  the  government  can  simply  disregard  such  a  restriction,  or  whether  the  data 
rights  clause  contractually  binds  the  government  to  respect  the  limitations  that  others  in  the  world 
are  free  to  ignore  is  a  close  question  (see  Aronson  v.  Quick  Point  Pencil  Co.  [20]  suggesting  that 
the  government  would  be  bound.) 

Because  copyright  law  does  not  give  the  copyright  owner  any  rights  to  control  "uses"  of  his  or  her 
work  (except  public  performances  and  displays),  it  may  be  that  both  DoD  and  NASA  could  adopt 
a  regulation  for  "published"  software  which  would  lift  restrictions  as  to  what  computers  or  facilities 
could  use  the  software. 


1.6  Issues  Arising  from  the  OSD  Technical  Data  Rights  Study 
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1.6.1  Fixed  Expirations  for  Restrictions 

In  September  1983,  the  Secretary  of  the  Air  Force,  Vernon  Orr,  issued  a  directive  [55]  (since 
modified)  requiring  that  a  clause  be  inserted  in  all  future  Air  Force  development  contracts  to 
provide  that  all  restrictions  on  technical  data  and  software  delivered  to  the  government  under 
contract  would  expire  no  later  than  five  years  after  delivery  (referred  to  below  as  “the  Orr  clause*). 
NASA  had  been  using  a  similar  clause  for  some  years.  This  idea  interested  one  of  the  com¬ 
mittees  of  the  House  of  Representatives  which  asked  OSD  to  study  the  idea.  The  OSD  Technical 
Data  Rights  Study  was  organized.  Its  report,  issued  in  June  of  1984  [11],  rejected  the  Orr  clause 
approach,  at  least  as  to  technical  data.  The  1985  DoD  Authorization  Act  gave  the  Secretary  of 
Defense  authority  to  issue  regulations  permitting  fixed  expiration  periods  of  up  to  seven  years. 
(See  [52]  sec.  2320(c).)  The  DAR  Council  studied  the  OSD  Study  Proposal  and  the  Authorization 
Act  and  issued  proposed  changes  to  the  DoD  FAR  SUPP  for  public  comment.  Those  proposed 
regulations  would  have  permitted  but  not  mandated  fixed  expiration  periods. 

From  the  standpoint  of  traditional  intellectual  property  theory,  fixed  expirations  for  restrictive 
legends  make  sense.  If  the  technical  data  or  software  being  delivered  is  not  inventive  enough  to 
be  patented,  why  should  the  government  create  what  is  in  essence  perpetual  protection  for  the 
thing  when  if  it  was  patented,  it  would  be  in  the  public  domain  after  17  years?  If  copyright  law 
would  not  protect  the  information,  ideas,  processes,  procedures,  and  other  valuable  things  con¬ 
tained  in  technical  data,  drawings  and  software,  why  should  the  government’s  data  rights  policy 
treat  them  as  protectable  property?  Intellectual  property  law  does  not  accept  the  idea  that  infor¬ 
mation  and  ideas  are  capable  of  being  ’owned*  by  anyone.  Even  traditional  trade  secret  law  does 
not  protect  any  ’property’  right  in  the  valuable  secret  per  se,  but  only  protects  the  confidential 
relationship  that  may  have  been  formed  when  one  person  disclosed  something  valuable  in  con¬ 
fidence  to  another,  or  protects  against  industrial  espionage  or  other  tortious  conduct  by  one  who 
wants  to  obtain  the  secret  [14].  Trade  secret  law  also  recognizes  that  over  time  old  technology 
may  become  less  valuable,  or  valueless,  which  makes  fixed  expirations  seem  reasonable.  It  is 
also  in  keeping  with  the  modem  law  of  trade  secrets  to  grant  injunctive  relief  only  for  the  period  of 
time  it  would  take  to  discover  the  secret  oneself  (and  if  that  time  is  past,  no  injunction  may  issue) 
and  to  grant  monetary  relief  for  a  similarly  limited  period. 

From  the  standpoint  of  how  industry  regards  its  secrets,  the  fixed  expiration  approach  poses 
some  difficulties.  Fixed  expiration  periods  are  sometimes  used  by  industry,  but  generally  in  the 
context  of  negotiations  focused  on  a  particular  item  of  software  to  be  acquired.  The  inflexible 
approach  of  the  original  Orr  directive  has  now  been  rethought  and  DoD  seems  to  have  kept  the 
option  but  allowed  greater  flexibility  about  it  in  the  acquisition  process.  It  may  be  possible  to 
provide  for  a  specification  during  the  planning  stage  or  system  acquisition  as  to  whether  an 
expiration  period  would  be  desirable,  and  if  so,  how  long  the  period  should  be. 
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1.6.2  "License  Rights" 

Apart  from  the  repudiation  of  the  fixed  expirations,  the  other  major  recommendation  of  the  OSD 
Technical  Data  Rights  Study  was  to  add  a  third  option  to  the  arsenal  of  potential  ways  to  get 
rights  to  technical  data.  Although  the  OSD  study  [11]  did  not  address  software  issues,  in  speak¬ 
ing  with  members  of  the  Study  Group,  it  was  clear  that  they  intended  the  'license  rights'  option  to 
be  applicable  to  software  as  well.  The  proposed  DoD  data  rights  regulations  issued  in  the  late 
summer  of  1985  would  create  a  new  'license  rights'  option,  although  the  intent  of  this  provision 
seems  to  be  somewhat  different  than  what  had  been  intended  by  the  OSD  Study  Group,  which  in 
turn  was  different  from  what  industry  had  in  mind  when  it  began  promoting  the  idea  of  'licensing*. 
It  may  be  helpful  to  lay  out  what  we  have  been  able  to  discern  as  to  the  thrust  of  the  OSD  study 
proposal,  of  the  industry  proposal,  and  of  the  proposed  regulations,  and  to  comment  on  each  in 
turn. 

What  we  take  to  be  the  aim  of  the  OSD  study  recommendation  is  to  enable  the  government  to 
impose  a  requirement  upon  its  contractors  that  they  license  competitors  to  make  use  of 
proprietary  data  in  competitive  reprocurement  (or  in  the  case  of  software, 
maintenance/enhancement)  situations.  Because  industry  strongly  objects  to  the  government 
simply  handing  proprietary  data  and  software  over  to  any  low  bidder  that  comes  along,  and  has 
been  arguing  forcefully  for  a  licensing’  approach  alternative,  adoption  of  a  proposal  of  this  sort 
may  be  an  important  step  in  improvement  in  relations  with  industry.  Implemented  in  an  optimal 
way.  the  OSD  Study  Proposal  might  even  save  DoD  a  lot  of  money.  It  is  worth  noting,  however, 
that  industry’s  intent  in  promoting  the  licensing  concept  seems  to  be  twofold:  first,  to  maximize 
the  amount  of  control  a  contractor  may  have  over  the  competitor  or  potential  competitor  as  to  its 
use  of  the  proprietary  software  (industry  wants  a  direct  relationship,  not  just  granting  power  to  the 
government  to  sublicense  whomever  it  pleases)  and  second,  to  begin  to  move  the  government 
closer  to  the  standards  that  prevail  in  the  commercial  arena  (See  e  g.,  [12]).  By  contrast,  the 
intent  of  the  recently  proposed  DoD  regulation  for  'license  rights'  seems  to  be  to  give  the  govern¬ 
ment  the  option  to  negotiate  expirations  for  restrictions  on  software  or  technical  data.  The  regula¬ 
tion  proposal  thus  would  shift  substantially  the  thrust  of  the  'license  rights*  proposal  as  originally 
conceived  by  the  OSD  Study  Group. 

The  major  reservation  we  have  about  the  OSD  Study  Proposal  and  the  proposed  regulation  is 
that  the  “license  rights'  option  may  not  be  explained  well  enough  for  contract  officers  and  other 
people  who  will  look  to  the  regulations  for  guidance  to  understand  the  intent  and  implement  it  as  it 
was  intended  to  be  implemented. 

To  be  more  specific,  one  of  the  problems  with  both  the  OSD  proposal  and  the  proposed  regula¬ 
tion  is  in  the  name  it  gives  the  option.  The  OSD  Study,  for  example,  states:  'Current  policy 
provides  only  two  recognized  ways  to  acquire  technical  data  rights:  Limited  and  unlimited.  The 
policy  should  be  expanded  to  include  licensing’  ( [11]  at  20).  The  ordinary  person  reading  this 
would  tend  to  think  that  'licensing*  must  be  something  different  from  limited"  or  ’unlimited"  rights, 
when  in  fact,  both  limited  and  unlimited  rights  seem  to  be  particular  types  of  licensing  arrange¬ 
ments.  (If  you  own  something,  you  own  something.  If  you  let  someone  else  use  that  thing,  you 
license  its  use,  regardless  ot  whether  you  give  the  person  a  broad  or  a  narrow  license.) 
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Here  is  a  second  problem  with  the  proposal.  The  ordinary  person  might  tend  to  wonder  whether 
'license  rights”  were  more  or  less  than  other  things.  The  ordinary  person  would  say,  "Well, 
'license  rights’  surely  has  to  be  less  than  unlimited  rights,  but  is  it  more  or  less  than  limited  (or  in 
the  case  of  software,  restricted)  rights?”  Now  on  the  one  hand,  it  would  seem  that  if  the  govern¬ 
ment,  in  getting  'license  rights,”  was  getting  the  right  to  show  the  valuable  data  or  software  of  one 
company  to  another  company  for  reprocurement  purposes,  it  would  seem  like  the  government 
was  getting  more  than  limited  or  restricted  rights  because  limited  and  restricted  rights  allow  only 
use  and  disclosure  within  the  government  (except  in  emergencies). 

On  the  other  hand,  from  talking  with  the  OSD  study’s  members  and  from  reviewing  the  OSD 
Study's  discussion  of  'direct  licensing,”  the  ordinary  person  might  well  think  that  this  proposal  was 
intended  to  enable  the  government  to  get  the  benefit  of  data  or  software  which  it  might  not 
possess,  but  which  a  third  party  might  have  gained  licensed  access  to.  In  other  words,  this  might 
be  a  way  for  the  government  to  get  the  benefit  of  certain  data  or  software  without  getting  any 
rights  or  less  than  minimum  rights  to  them.  So  this  would  tend  to  make  someone  think  it  was  less 
than  limited  or  restricted  rights.  If  this  was  intended,  then  the  regulations  would  have  to  make  this 
very  clear. 

Furthermore,  if  all  one  wanted  was  a  middle  ground  between  ’unlimited”  and  ’limited”  rights,  it 
isn't  clear  that  a  special  'license  rights”  provision  is  necessary.  The  present  ’limited  rights’  and 
'restricted  rights*  provisions  already  allow  for  a  middle  ground.  With  the  original  contractor’s  writ¬ 
ten  permission,  it  has  always  been  possible  to  give  out  to  another  contractor  limited  rights  tech¬ 
nical  data  or  restricted  rights  software.  There  is  no  prohibition  against  getting  that  written  permis¬ 
sion  in  the  original  contract. 

What  DoD  seems  really  to  need  is  not  a  middle  ground,  but  a  contractual  commitment  from  the 
original  contractor  to  agree  to  one  of  three  things:  (1)  to  license  the  government  to  sublicense  a 
second  firm  for  reprocurement  or  maintenance  purposes,  (2)  to  enter  into  a  license  agreement 
with  a  second  firm  to  allow  it  to  use  the  data  or  software  for  reprocurement  or  maintenance 
purposes,  or  (3)  to  allow  restrictions  on  the  government's  use  and  disclosure  to  expire  after  a 
period  of  time  so  that  competitive  maintenance  or  reprocurement  can  occur.  If  the  commitment  to 
allow  third  party  access  for  maintenance  or  reprocurements  is  what  is  truly  needed,  any  such 
regulation  should  say  so  very  clearly.  Neither  the  OSD  Study  Proposal  nor  the  recently  issued 
proposed  DoD  regulation  on  license  rights  provides  this  clear  guidance. 

Yet  another  problem  with  both  the  OSD  Study  Proposal  and  the  proposed  DoD  regulations  con¬ 
cerning  "license  rights"  is  that  there  is  already  one  set  of  "license  rights’  in  the  DoD  FAR  SUPP 
( [61]  sec.  52.227-7025).  It  is  downright  confusing  to  have  two  entirely  different  'license  rights” 
clauses  in  the  same  set  of  regulations  (one  applicable  to  SBIR  and  one  applicable  to 
reprocurements).  The  OSD  Study  would  not  have  revised  the  existing  definition  of  'license  right" 
(although  the  current  definition  only  gives  the  government  the  right  to  sublicense  "for  governmen¬ 
tal  purposes."  This,  unfortunately,  begs  the  question  whether  competitive  reprocurements  are 
within  the  meaning  of  that  phrase).  The  proposed  DoD  regulations  give  license  rights  two  different 
meanings  which  only  exacerbates  the  problem.  If  the  narrow  interpretation  of  'unlimited  rights"  is 


accurate  (discussed  in  Section  1.3.1),  and  that  term  means  only  a  license  to  use  for  governmen¬ 
tal  purposes  and  to  sublicense  for  the  same,  then  there  would  be  no  difference  between  the  OSD 
Study  "license  rights"  option  and  "unlimited  rights." 

Furthermore,  the  OSD  Study  draft  reprocurement  license  clause  was  long,  complex,  and  unclear. 
(For  instance,  it  often  referred  to  "direct  license  rights"  which  it  did  not  define.  Is  this  a  direct 
license  between  the  contractor  and  the  government,  or  a  license  between  two  contractors?)  The 
OSD  draft  license  rights  clause  also  seems  to  be  written  as  though  rt  is  unrelated  to  the  standard 
data  rights  clause  although  in  fact  it  would  modify  it.  The  aim  of  the  draft  clause  seems  to  be  only 
to  address  the  spare  parts  reprocurement  issue,  although  the  need  for  licenses  to  get  competition 
may  be  broader  than  that  (e.g.,  software  maintenance).  Software  is  not  mentioned  at  all,  and  the 
draft  license  rights  clause  would  not  be  readily  adaptable  to  software. 

Industry  would  seem  to  have  a  decided  preference  that  if  another  firm  has  to  be  licensed  to  use 
the  first  firm's  trade  secrets,  the  two  firms  make  arrangements  directly  so  that  in  the  event  of  an 
abuse,  the  first  firm  can  proceed  directly  against  the  second  firm  rather  than  have  to  try  to  push 
the  government  to  do  something.  Industry  also  doesn’t  like  the  government  to  dictate  or  supervise 
terms  of  licenses.  The  OSD  draft  clause  accepts  the  industry  preference  for  contractor-to- 
contractor  licenses.  It  is  worth  noting  (as  unfortunately  the  OSD  study  does  not)  that  there  are 
serious  dangers  of  overreaching  (exclusionary  conduct  in  antitrust  parlance)  by  the  original  con¬ 
tractor  in  any  arrangement  which  would  involve  licensing  of  competitors  as  to  valuable  tech¬ 
nologies.  If  the  government  does  not  want  to  end  up  paying  through  licensing  essentially  the 
same  amount  as  if  there  had  been  a  sole  source,  some  government  supervision  of  the  terms  and 
conditions  of  the  license  would  seem  to  be  necessary  in  direct  competitor  situations. 

The  license  rights  option,  as  reflected  in  the  proposed  DoD  regulations,  is  a  far  cry  from  the 
license  rights  proposal  that  industry  has  been  promoting.  It  is  far  from  clear  that  the  new  DoD 
option  will  be  acceptable  to  industry  which  can  always  opt  to  stick  with  limited  or  restricted  rights 
for  valuable  technologies. 

1.6.3  Predetermination  (to  be  Renamed  as  Prenotification)  of  Rights 

The  OSD  Study  favored  use  of  a  predetermination  of  rights  clause  in  all  development  contracts 
although  the  Study  thought  it  should  be  called  a  "prenotification"  clause  instead  of  a  predeter¬ 
mination  clause.  The  clause,  in  essence,  requires  the  parties  to  identify  all  software  and  technical 
data  that  will  be  delivered  under  the  contract  with  restrictions  on  the  government’s  use  of  it.  Many 
of  the  DoD  personnel  to  whom  we  spoke  supported  use  of  this  clause.  Some  regarded  it  as 
essential.  While  the  aim  of  the  clause  --  to  clarify  data  rights  as  much  as  possible  at  the  outset  - 
is  laudable,  many  people  in  the  field  regard  the  clause  as  unrealistic  and  unworkable,  especially 
as  to  software.  How  can  one  say  what  rights  the  government  will  get  in  software  from  third  tier 
subcontractors  when  the  software  may  not  yet  exist,  or  if  it  does,  the  prime  may  not  yet  have 
identified  who  will  deliver  it,  let  alone  with  what  rights?  One  person  likened  the  predetermination 
process  to  asking  Lewis  and  Clark  to  prepare  a  set  of  "triptiks"  for  their  exploration  of  the  Oregon 
Territory  before  they’d  set  out  on  their  journey. 


35 


1.7  Rethinking  and  Simplifying  DoD’s  Data  Rights 

As  DoD  well  knows,  industry  people  have  a  lot  of  complaints  about  the  DoD  procurement  regula¬ 
tions.  especially  as  they  affect  software  data  rights.  "Revise  Part  27.4  of  the  DoD  FAR  SUPP," 
they  are  wont  to  say.  Just  how,  they  do  not  usually  say,  or  if  they  do,  they  tend  tc  pull  out  a  huge 
laundry  list  of  grouses  and  do  not  differentiate  among  them  at  all. 

We  take  as  "givens"  much  of  what  industry  doesn’t  like  about  government  procurement  practices 
(e  g.,  the  auditing  of  the  books,  the  limits  on  profits,  the  record  keeping  requirements)  and  much 
of  what  the  government  has  insisted  it  needs  (more  rights  than  industry  commonly  gives  to  its 
commercial  customers,  especially  as  to  reprocurements  and  maintenance.) 

On  the  other  hand,  perhaps  a  revision  of  the  procurement  regulations  as  to  data  rights  would  be  a 
good  idea.  A  lot  of  DoD  people,  particularly  those  who  are  actually  doing  procurements,  favor  the 
idea. 

Doing  so  might  be  a  step  toward  improvement  of  relations  with  industry.  And  if  the  government 
can  clarify  what  its  priorities  are  in  the  data  rights  area,  perhaps  it  can  strike  a  balance  with 
industry  to  get  a  little  more  of  what  it  truly  needs  to  achieve  competition  in  reprocurements, 
maintenance,  and  enhancements,  by  giving  up  a  little  of  what  it  already  has,  but  does  not  truly 
need,  perhaps  trimming  back  somewhat  on  its  unlimited  rights  policy.  At  the  same  time  perhaps 
the  government  can  simplify  the  regulations  and  make  them  more  comprehensible  which  would 
be  a  benefit  both  to  the  government  and  industry. 

1.7.1  Comprehensibility  as  a  Goal  of  the  Regulations 

One  of  the  priorities  DoD  should  have  for  its  data  rights  regulations  is  having  regulations  which 
are  as  simple,  straightforward  and  clear  as  possible.  The  current  DoD  data  rights  regulations  fall 
short  of  this  goal. 

Procurement  regulations  -  especially  as  to  data  rights  -  need  to  be  readily  understood  and  applied 
by  people  of  ordinary  intelligence  who  aren’t  lawyers  and  who  often  have  to  work  under  extreme 
pressure  and  have  many  things  to  worry  about  besides  data  rights.  Given  this,  one  can  perhaps 
see  the  value  of  at  least  attempting  a  more  simple,  straightforward  approach.  When  a  contracting 
officer  is  being  rushed  to  field  a  system,  and  when  future  promotions  will  ride  on  how  quickly  he  is 
able  to  field  that  system,  he  is  likely  to  avoid  becoming  enmeshed  in  complicated  data  rights 
issues  which  he  will  likely  not  understand  all  that  well  to  begin  with  and  which,  if  he  pursues  their 
depths,  will  surely  slow  the  procurement  process  down.  If  the  system  is  fielded  with  inadequate 
data  rights  for,  say,  organic  maintenance/enhancement  purposes,  well,  that  will  be  someone 
else’s  problem  anyway.  A  more  streamlined,  understandable  regulatory  structure  might  help  the 
contracting  officers  to  overcome  their  reluctance  to  address  data  rights  issues. 

One  good  example  of  how  the  regulations  unnecessarily  complicate  ^jta  rights  matters  is  the 
provisions  for  two  kinds  of  restricted  rights  for  software  and  yet  another  set  of  restrictions  ("limited 
rights’)  for  technical  data  (See  section  1 .3.4).  It  is  difficult  to  understand  why  there  are  two  kinds 
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of  restricted  rights  for  software  and  yet  another  set  of  restrictions  ('limited  rights")  for  technical 
data.  It  is  also  difficult  to  comprehend  why  the  regulations  subject  software  documentation  (which 
is  classified  as  "technical  data")  to  different  restrictions  than  machine-readable  code  (i.e., 
"software").  This  doesnl  seem  to  make  sense  given  that  in  the  commercial  market  these  things 
are  treated  as  subject  to  the  same  restrictions.  Why  one  would  treat  documentation  for  commer¬ 
cial  software  differently  than  other  software  documentation  is  also  mysterious. 

Even  if  there  is  good  justification  for  treating  technical  data  other  than  software  documentation 
differently  than  software,  it  doesnl  make  sense  to  have  two  so  similar  and  yet  not  identical  sets  of 
restricted  rights  for  software.  What  DoD  seems  to  need  to  do  is  set  a  "floor"  of  minimum  rights  it 
must  always  get  in  software  (perhaps  to  be  named  "minimum  rights")  and  then  let  the  parties 
negotiate  other  rights  and  restrictions  (perhaps  to  be  stamped  "negotiated  rights  -  see  Contract 

No. _ ")  as  they  see  fit.  The  proposal  found  at  the  end  of  this  section  attempts  to  develop  a 

set  of  minimum  rights  for  software  and  technical  data  (lumped  together  under  the  definition  of 
intellectual  property).  Simplifying  these  provisions  would  also  eliminate  the  "booby  traps"  that  the 
current  regulations  set  for  the  unwary  business,  as  well  as  eliminating  the  "booby  traps’  that 
might  close  on  the  government. 

1.7.2  Not  Getting  as  Many  Rights  as  DoD  Needs 

It  is  understandable  that  in  reaction  to  the  spare  parts  competition  problems  which  were  due  in 
part  to  the  government  having  gotten  inadequate  rights  to  certain  technical  data  and  which  have 
come  under  intense  Congressional  scrutiny,  DoD  would  make  efforts  to  adopt  policies  aimed  at 
assuring  that  such  problems  would  not  occur  in  the  future.  The  seemingly  obvious  ways  to  ac¬ 
complish  this  are  either:  (a)  to  acquire  unlimited  rights  in  all  technical  data  and  software  (either 
initially  or  through  fixed  expirations  on  restrictions)  or  (b)  to  get  the  option  to  allow  the  government 
to  acquire  at  a  later  time  unlimited  rights  to  technical  data  or  software  for  a  price  negotiated  at  the 
time  the  contract  was  made.  Both  would  seem  to  achieve  the  objective  sought  (being  free  of 
restrictions  on  use  and  disclosure),  but  at  a  very  high  cost.  Industry  has  been  outraged  by  efforts 
of  these  sorts  and  has  apparently  expressed  their  outrage  by  pricing  their  technology  at  stratos¬ 
pheric  levels.  Perhaps  such  approaches  were  overreactions  to  the  problem.  Not  having  asked  for 
enough  for  awhile,  now  perhaps  the  government  was  asking  for  more  than  it  needed,  and  the 
problem  deepened  rather  than  being  resolved. 

What  was  true  when  the  procurement  scandals  "broke"  -  and  what  probably  remains  true  today 
-  is  that  there  are  instances  in  which  the  government  is  not  getting  as  much  data  rights  as  it 
needs.  The  two  areas  as  to  which  we  have  reason  to  think  present  data  rights  policies  may  be 
insufficient  pertain  to  use  and  disclosure  of  technical  data  to  third  parties  for  spare  parts 
reprocurement  purposes,  and  use  and  disclosure  of  software  and  documentation  to  third  parties 
for  maintenance  or  enhancement  purposes.  Perhaps  specific  provisions  could  be  written  to  ac¬ 
complish  these  objectives.  As  the  discussion  of  "license  rights"  above  indicates,  some  efforts  are 
in  the  process  of  being  made  to  do  this,  at  least  as  to  technical  data.  A  more  limited  reaction  is 
one  which  industry  may  be  willing  to  try  to  live  with. 
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1.7.3  Getting  More  Rights  Than  DoD  Needs 

Government  procurement  people  frequently  say  (and  there  is  even  a  DoD  regulation  to  back  it 
up)  that  it  is  the  policy  of  the  Defense  Department  to  acquire  only  so  much  rights  as  the  govern¬ 
ment  needs  ( [61]  sec.  27.403-2(a)).  The  truth  is  that  DoD  routinely  acquires  more  rights  than  it 
needs.  Its  practice  reveals  that  its  priorities  often  lie  elsewhere. 

Perhaps  the  clearest  illustration  of  overacquisition  of  rights  is  the  government's  standard  policy  of 
acquiring  unlimited  rights  in  software  and  data  produced  at  government  expense,  even  as  to  what 
is  non-deliverable  under  the  government  contract.  The  government  doesn't  always  need  to  have 
unlimited  rights  in  these  items  although  perhaps  sometimes  it  does.  Another  illustration  is  its 
insistence  on  treating  many  things  clearly  not  in  the  public  domain  and  not  developed  at  public 
expense  (such  as  manuals)  as  subject  to  unlimited  rights.  Still  another  illustration  is  its  policy  of 
treating  something  as  having  been  developed  at  government  expense  if  so  much  as  $1  (or  for 
that  matter,  a  dime)  of  government  money  has  been  spent  in  its  development,  which  of  course 
will  mean  that  the  government  will  get  unlimited  rights  in  it.  Again,  it  isn't  the  case  that  the  govern¬ 
ment  always  needs  all  those  additional  rights,  especially  since  if  that  $1  of  government  money 
had  not  been  spent  on  ’fine-tuning*  the  product,  the  government  would  have  contented  itself  with 
restricted  rights  to  the  proprietary  software.  The  vigilant  search  by  government  lawyers  for  some 
technical  defect  in  compliance  with  the  DoD  FAR  SUPP  to  enable  the  government  to  get  un¬ 
limited  rights  in  something  which  both  parties  reasonably  expected  to  be  subject  to  restrictions 
(the  price  itself  also  reflecting  the  expectation  of  restrictions)  would  be  viewed  by  industry  as  yet 
another  instance  of  the  government  searching  for  more  rights  than  perhaps  it  truly  needs  (and 
has  paid  for). 

From  our  interviews  with  DoD  personnel,  it  appears  that  getting  unlimited  rights  in  publicly  funded 
software  and  technical  data  is,  for  many  people,  a  fixed  star  in  the  firmament  of  the  DoD  procure¬ 
ment  universe.  Industry  seems  to  have  adjusted  to  it,  although  this  is  one  of  its  least  favorite 
government  policies. 

There  is  a  certain  elemental  appeal  to  the  policy.  People  generally  tend  to  think  that  if  they  pay 
money  to  have  something  made  for  them,  they  ’own*  it  and  should  be  able  to  do  with  it  as  they 
please.  Government  people  frequently  express  this  kind  of  sentiment  toward  the  spending  of 
government  money,  and  seem  not  to  understand  why  private  firms  might  object  to  the  policy.  The 
private  firms,  of  course,  tend  to  think  that  the  government  is  trying  to  get  something  for  nothing. 

The  truth  is  that  private  firms  understand  this  principle  of  getting  all  the  rights  and  benefits  when 
one  pays  for  something  very  well  when  it  comes  to  their  rights  as  against  those  of  their 
employees.  Within  a  firm,  ownership  of  intellectual  property  and  profits  resulting  from  the  value  of 
the  intellectual  property  do  not  go  to  the  creative  employee,  but  to  the  shareholders  of  the  firm. 
(But  then,  that  is  the  essence  of  the  free  enterprise  system  which  the  Department  was  created  to 
defend.) 

Yet  government  people  do  understand  -  even  if  they  don’t  much  like  it  -  that  private  firms  seem 
to  lack  incentives  to  develop  and  deliver  their  best  products  to  the  government  when  the  firms 
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have  no  reasonable  expectation  of  receiving  a  continuing  stream  of  income  from  the  product,  and 
that,  as  a  result,  the  government  isnl  getting  the  best  technology.  Some  government  people 
might  think,  "a  private  firm  has  incentive  to  deliver  the  best  software  to  us  (even  though  we  have 
unlimited  rights)  because  it's  OK  with  us  if  they  take  the  thing  to  the  commercial  market.* 

There  are  a  couple  of  problems  with  this  theory.  One  is  that  since  the  government  claims  an 
unlimited  right  to  disclose  the  software  developed  at  public  expense  to  any  one  for  any  purpose, 
the  government  always  has  the  power  to  pull  the  rug  out  from  under  the  commercial  market  (for  in 
today’s  market,  it  is  the  valuable  secrets  embodied  in  the  software  that  seem  to  determine  its 
commercial  value).  This  means  the  firm  can  never  be  sure  there  will  be  a  commercial  market 
there  to  tap.  Secondly,  the  government  sometimes  wants  to  ’give  away*  valuable  software  in 
which  it  has  unlimited  rights  to  other  private  defense  firms  to  enable  those  firms  to  perform  better 
work  on  government  projects.  The  problem  is  that  the  software's  developer  may  see  these  other 
defense  firms  as  its  primary  commercial  market.  This  too  can  undermine  the  potential  incentives 
that  government  people  tend  to  think  the  private  firm  has  retained. 

It  is  worth  pointing  out  that  Congress  has  enacted  a  law  to  encourage  small  firms  to  develop  and 
deliver  to  the  government  the  highest  quality,  most  innovative  products,  namely  the  Small  Busi¬ 
ness  Innovation  Development  Act  [68]  which  gives  participating  small  firms  the  right  to  retain 
ownership  rights  in  patents  developed  at  public  expense,  with  a  license  back  to  the  government 
to  use  the  patent  for  governmental  purposes.  Previously  the  government  could  have  taken  owner¬ 
ship  of  patents  developed  at  public  expense.  It  is  not  surprising  that  software  firms  hail  the  SBIDA 
as  the  "enlightened"  and  "modem"  policy  that  the  government  should  follow  as  to  software. 

As  far  as  we  are  concerned,  the  government  is  welcome  to  retain  its  broad  unlimited  rights  policy. 
It  just  shouldn’t  be  surprised  if  this  policy  results  in  its  getting  less  high  quality  products.  Whether 
it  should  retain  this  policy  or  narrow  it  to  a  governmental  purpose  policy  depends  on  what  its 
goals  are.  If  the  primary  goal  is  to  get  the  best  available  technology  and  improve  incentives,  it 
should  adopt  the  SBIDA  approach.  If  its  primary  goal  is  to  get  as  much  data  rights  as  it  possibly 
can  in  hopes  that  will  save  money  down  the  line,  it  should  stick  with  unlimited  rights. 

It  might  be  wise  for  the  government  to  consider  voluntarily  giving  up  its  broad  unlimited  rights 
policy  for  software  and  explicitly  adopting  a  policy  more  in  line  with  the  SBIR  policy  as  to  patents, 
or  adopting  a  policy  under  which  the  government  would  take  less  than  unlimited  rights  when 
mixed  funding  was  used  for  software  development.  This  might  be  a  step  toward  improving  rela¬ 
tions  with  industry  without  giving  up  what  the  government  truly  needs.  The  government  may  still 
wish  to  retain  the  power  to  obtain  ownership  rights  in  intellectual  property  when  achievement  of 
certain  well  defined  goals  would  seem  to  require  broader  control  than  simply  a  license  to  use  for 
governmental  purposes.  But  it  might  be  easier  for  industry  to  aocept  the  government's  need  to 
sublicense  for  reprocurement  and  maintenance  purposes  if  the  government  was  willing  to  trim 
back  somewhat  its  unlimited  rights  policy. 


1.7.4  Proposed  Alternative  Data  Rights  Clauses 

There  are  many  ways  a  standard  data  rights  clause  for  DoD  might  be  structured  and  written. 
Among  the  problems  with  the  existing  standard  data  rights  clause  is  its  great  length  (nine  pages) 
and  its  turgidity.  It  is  a  clause  which  has  been  much  amended,  as  first  this  situation,  then  that,  is 
taken  into  account.  The  amendments  have,  unfortunately,  not  always  been  simple,  straightfor¬ 
ward,  unambiguous  and  comprehensible.  Perhaps  it  is  time  for  a  fresh  start.  Over  time  a  new 
clause  may  also  become  encrusted,  but  at  least  for  a  while,  it  may  be  an  improvement. 

Even  without  altering  the  substance  of  the  data  rights  clause,  DoD  might  be  able  to  get  some 
"mileage”  from  a  revision  of  the  standard  data  rights  clause  that  would  make  the  clause  more 
readable  and  less  ambiguous.  One  of  industry's  standard  complaints  about  the  clause  is  its 
Jesuitical  complexity,  a  complaint  which  could  be  eliminated  by  such  a  revision. 

The  draft  alternative  data  rights  clause  found  below  does  not  retain  all  of  the  substantive  provi¬ 
sions  of  the  existing  data  rights  clause.  It  drops,  for  example,  the  claim  to  unlimited  rights  in 
non-deliverables  produced  at  government  expense  on  the  ground  that  this  provision  serves  only 
to  frustrate  the  government  when  it  believes  it  has  rights  it  cannot  enforce.  On  the  other  hand,  it 
gives  the  government  back  its  unlimited  rights  in  copyrighted  material  produced  at  government 
expense.  And  it  defines  unlimited  rights  in  a  broader  manner  so  as  to  allow  creation  of  derivative 
works,  among  other  things.  This  draft  is  offered  simply  as  an  item  for  consideration,  as  something 
to  think  about  if  DoD  decides  that  a  revision  of  the  standard  data  rights  clause  might  be  desirable. 

Following  the  draft  clause  is  a  short  discussion  of  two  other  possible  alternative  draft  clauses,  one 
of  which  industry  people  might  greet  as  reflecting  a  more  “enlightened”  policy,  and  one  of  which 
we  suggest  might  be  a  workable  compromise  of  the  government’s  and  of  industry’s  concerns. 

1.7.5  An  Alternative  Standard  Data  Rights  Clause 
Rights  of  the  Government 

(1 )  Unlimited  Rights  Licenses:  The  government  shall  have  unlimited  rights  in: 

(i)  all  intellectual  property  to  be  delivered  under  this  contract  which  was  developed  at  public 
expense; 

(ii)  all  intellectual  property  to  be  delivered  under  this  contract  which  is  in  the  public  domain  or 
otherwise  distributed  without  restriction; 

(iii)  all  intellectual  property  to  be  delivered  under  this  contract  which  incorporates  intellectual 
property  in  which  the  government  already  has  unlimited  rights;  and 

(iv)  all  intellectual  property  delivered  under  this  contract  which  is  not  properly  marked  as  to  the 
restrictions  pertaining  to  it. 

(2)  Minimum  Rights  Licenses:  The  government  shall  have  a  minimum  rights  license  in  all  intel¬ 
lectual  property  delivered  under  this  contract  which  has  been  developed  at  private  expense.  Writ¬ 
ten  permission  of  the  owner  of  such  intellectual  property  will  be  required  before  the  government 
may  make  other  uses  or  disclosures  of  this  intellectual  property. 


(3)  Other  Licenses  Possible:  When  the  government  needs  to  have  more  than  minimum  rights  in 
certain  intellectual  property,  the  government  and  contractor  can  enter  into  other  licensing  ar¬ 
rangements,  but  in  no  event  can  the  government  enter  into  a  licensing  agreement  for  intellectual 
property  which  gives  the  government  less  than  minimum  rights. 

Rights  of  the  Contractor 

(1)  Ownership:  The  contractor  shall  be  considered  the  owner  of  all  intellectual  property 
developed  at  public  expense  under  this  contract,  except  as  to  contracts  in  which  the  special 
works  clause  is  used,  subject  only  to  granting  the  government  an  unlimited  rights  license  to  the 
intellectual  property. 

(2)  Copyright:  The  contractor  may  obtain  and  retain  a  copyright  on  all  intellectual  property 
delivered  to  the  government  under  this  contract  except  when  the  special  works  clause  is  used. 
The  contractor's  obtaining  of  a  copyright  shall  not  limit  the  government’s  rights  under  its  unlimited 
rights,  minimum  rights,  or  any  other  license. 

(3)  Restrictive  Markinas:  The  contractor  may  attach  appropriate  restrictive  legends  to  its  intel¬ 
lectual  property,  as  set  forth  below  in  section  (d). 

Rights  of  Subcontractors 

(1)  Getting  Same  Data  Rights  From  Subcontractor:  Whenever  intellectual  property  is  to  be  ob¬ 
tained  from  a  subcontractor  under  this  contract,  the  parties  shall  use  this  same  clause  in  the 
subcontract,  without  alteration.  No  other  clause  shall  be  used  to  diminish  or  enlarge  the 
government’s  or  contractor's  rights  in  the  subcontractor's  intellectual  property  required  for  the 
government. 

(2)  Direct  Delivery  to  the  Government:  Subcontractors  under  this  contract  may  deliver  technical 
data  in  which  the  government  will  have  less  than  unlimited  rights  directly  to  the  government  rather 
than  through  the  prime  contractor. 

(3)  Ng  Leverage:  The  contractor  and  higher-tier  subcontractors  shall  not  use  their  power  to 
award  subcontracts  as  economic  leverage  to  acquire  rights  in  intellectual  property  from  their 
subcontractors  for  themselves. 

(4)  Right  1q  Attach  Restrictive  Markinas:  Subcontractors  under  this  contract  shall  have  the  same 
rights  to  attach  restrictive  markings  to  their  intellectual  property  as  the  contractor  does  to  intel¬ 
lectual  property. 

Restrictive  Legends 

(1)  No  Markina  If  Unlimited  Rights:  Intellectual  property  in  which  the  government  has  unlimited 
rights  shall  be  delivered  with  no  restrictive  markings.  Unmarked  items  delivered  under  this  con¬ 
tract  will  be  presumed  to  be  items  in  which  the  government  has  unlimited  rights. 


(2)  Minimum  Rights  Legend:  Intellectual  property  in  which  the  government  has  only  minimum 
rights  must  be  delivered  with  a  restrictive  marking  of  the  following  type: 

Minimum  Rights 

Property  of:  (contractor  or  subcontractor's  name) 

(3)  Restrictive  Legend  for  Other  Licenses:  Intellectual  property  delivered  to  the  government  un¬ 
der  other  kinds  of  licensing  arrangements  must  be  delivered  with  the  following  restrictive  marking: 

Negotiated  Rights 

Property  of:  (contractor  or  subcontractor) 

Contract  No: _ 

(4)  Substantiating  Restrictive  Legends:  The  government  may  challenge  restrictive  legends  at¬ 
tached  to  intellectual  property  delivered  or  intended  to  be  delivered  under  this  contract  on  the 
ground  that  public  funds  were  used  to  develop  the  intellectual  property.  Within  60  days  after  a 
written  request  for  substantiation  of  a  restrictive  legend,  the  contractor  or  subcontractor  shall 
provide  clear  and  convincing  evidence  that  the  intellectual  property  was  developed  wholly  at 
private  expense.  If  the  contract  officer  finds  that  the  intellectual  property  was  not  developed 
wholly  at  private  expense,  the  government  may  ignore  or  cancel  the  restrictive  legends. 

(5)  Right  to  Appeal  Cancellations  gf  Restrictive  Legends:  If  the  contract  officer  finds  that  intel¬ 
lectual  property  delivered  under  this  contract  with  restrictive  rights  has  not  been  developed  wholly 
at  private  expense,  the  contractor  or  subcontractor  shall  have  the  right  to  appeal  any  decision  of 
the  government  to  cancel  or  ignore  the  restrictive  marking  in  accordance  with  the  provisions  of 
the  Contracts  Dispute  Act. 

(6)  Contractor  Challenges  to  Subcontractor  Restrictive  Legends:  When  a  subcontractor  delivers 
to  the  contractor  any  intellectual  property  for  eventual  delivery  to  the  government  under  this  con¬ 
tract,  and  the  intellectual  property  is  marked  with  a  restrictive  legend  which  the  contractor 
believes  to  be  inappropriate,  the  contractor  shall  notify  the  contract  officer  of  the  inappropriate 
legend  so  that  the  contract  officer  may  challenge  it. 

Definitions 

[NOTE:  Only  the  definitions  to  be  changed  are  mentioned  here.  Additional  definitions  of  such 
terms  as  "developed  at  public  expense"  and  "government  purpose*  are  not  offered  here,  although 
they  too  should  be  added.] 

The  following  terms  used  in  this  clause  have  the  following  meanings: 

(1)  Unlimited  Rights:  "Unlimited  rights"  means  the  right  to  use,  copy,  disclose,  distribute,  per¬ 
form,  display,  and  prepare  derivative  works  of  intellectual  property,  in  whole  or  in  part,  in  any 
manner  and  for  any  purpose  whatsoever,  and  to  have  and  permit  others  to  do  so. 

(2)  Intellectual  Property:  "Intellectual  property"  refers  to  technical  data  and  oomputer  software. 


(3)  Computer  Software:  'Computer  software"  means  all  firmware,  software,  data  bases,  and 
documentation  for  the  same. 

(4)  Technical  Data:  "Technical  data"  means  [same  as  the  current  definition  but  excluding  com¬ 
puter  software  documentation]. 

(5)  Minimum  Rights:  "Minimum  rights"  means: 

(a)  as  to  technical  data,  the  right  to  use,  copy,  and  disclose  the  material  within  the  government, 
and 

(b)  as  to  computer  software,  the  right  to 

(i)  use  it  at  the  facility  for  which  it  was  acquired  or  to  which  it  is  transferred; 

(ii)  the  right  to  use  it  with  a  back-up  computer  if  the  computer  for  which  it  was  acquired 
becomes  inoperative; 

(iii)  make  back-up  copies  for  safekeeping,  and  for  modification  purposes; 

(iv)  modify  it.  or  combine  it  with  other  software  (modification  will  not  alter  restrictions  on  the 
software). 

[end  of  clause] 

Additionally.  DoD  might  want  to  develop  standard  licensing  clauses  giving  the  government  the 
right  to  sublicense  use  of  proprietary  intellectual  property  for  competitive  reprocurement  or  com¬ 
petitive  software  maintenance  purposes,  subject  to  appropriate  restrictions  on  any  third  party  use 
of  this  property.  In  Chapter  2  we  offer  some  suggestions  about  how  the  potential  for  competition 
in  software  maintenance  situations  could  be  maximized. 

Another  thing  that  might  be  desirable  to  consider  is  the  development  of  one  standard  data  rights 
clause  for  all  intellectual  property,  including  patents  and  chips,  which  would  define  the  minimum 
rights  in  each  respective  type  of  subject  matter  in  the  definition  of  "minimum  rights."  It  does  not 
seem  desirable  to  have  a  wholly  different  policy  (and  structure  for  that  policy)  for  patents  and  for 
other  types  of  intellectual  property.  Integration  at  least  ought  to  be  considered,  and  hopefully 
attempted. 

If  the  alternative  draft  clause  set  forth  above  was  adopted  by  DoD,  it  would  remove  some  of 
industry’s  complaints  about  it,  but  that  might  only  serve  to  sharpen  the  areas  of  disagreement. 
Industry  would  like  for  DoD  to  give  up  claiming  'unlimited  rights"  in  software  and  technical  data 
developed  at  public  expense,  and  to  adopt  a  policy  of  only  taking  what  the  current  regulations  call 
"license  rights"  in  these  things,  that  is,  a  license  to  use  intellectual  property  for  governmental 
purposes  and  to  sublicense  for  the  same  purposes.  Industry  regards  this  SBIR-type  approach  as 
the  "modem"  and  "enlightened"  solution  to  data  rights  acquisitions.  Only  modest  changes  to  the 
draft  clause  above  would  be  necessary  to  incorporate  this  industry  preference  in  the  standard 
data  rights  clause.  An  intermediate  position  would  be  to  have  the  government  take  unlimited 
rights  in  things  completely  funded  by  the  government,  and  only  a  governmental  purpose  license 


in  things  funded  only  in  part  with  government  money.  The  1985  OoO  Authorization  Act  (creating 
10  U.S.C.,  sec.  2320(a)  [52])  suggests  this  may  be  compatible  with  Congressional  thinking. 

A  second  variation  on  the  draft  standard  data  rights  clause  above,  which  we  would  have  DoD 
consider  would  be  one  that  would  have  the  government  bend  to  industry’s  demands  for  getting 
only  a  governmental  purpose  license  as  to  intellectual  property  developed  at  public  expense 
instead  of  “unlimited  rights’  and  would  require  industry  to  bend  by  giving  DoD  the  right  to  sub¬ 
license  for  competitive  reprocurement  or  maintenance  purposes  (subject  to  appropriate  restric¬ 
tions  on  the  third  party)  as  part  of  its  “minimum  rights.*  Again,  only  modest  changes  in  the  draft 
above  would  seem  to  be  required  to  accomplish  this.  If  getting  competition  for  reprocurement  and 
maintenance  purposes  is  a  high  priority  of  DoD,  it  may  be  worthwhile  to  consider  whether  the 
government  can  live  with  being  able  to  use  and  sublicense  use  of  intellectual  property  for 
governmental  purposes.  If  it  can,  maybe  this  wouldn't  be  a  bad  deal  to  make. 

1.8  Recently  Proposed  Revisions  to  the  DoD  Procurement  Regulations 

Until  recently,  there  has  been  no  substantive  “data  rights*  policy  under  the  FAR.  Because  DoD 
has  long  needed  to  have  a  standard  policy  for  acquiring  rights  in  software  and  technical  data, 
DoD  developed  its  own  elaborate  policy,  which  is  currently  embodied  in  the  DoD  FAR  SUPP 
( [61],  Subpart  27.4). 

The  Competition  in  Contracting  Act  (CICA)  [57],  passed  last  year,  required  development  of  a 
substantive  data  rights  policy  for  all  federal  agency  acquisitions.  Both  CICA  and  the  1985  DoD 
Authorization  Act  reflect  Congress'  intent  that  there  be  a  uniform  data  rights  policy  for  all  federal 
agencies.  The  newly  proposed  Subpart  27.4  of  the  FAR  is  the  substantive  data  rights  policy  that 
was  developed  to  respond  to  this  Congressional  mandate. 

Shortly  after  issuance  of  the  newly  proposed  FAR  data  rights  provisions,  DoD  issued  a  set  of 
proposed  revisions  to  the  DoD  FAR  SUPP.  Although  said  to  "supplement"  the  FAR,  the  proposed 
DoD  regulations,  if  adopted,  will  entirely  supplant  the  FAR. 

Supplantation  of  the  FAR  is  inconsistent  with  the  Congressional  mandate  for  a  uniform  policy  for 
federal  acquisitions.  Because  of  this  and  because  the  proposed  FAR  contains  a  superior  data 
rights  policy,  one  which  is  more  straightforward  and  concise,  more  consistent  with  commercial 
practice,  and  more  compatible  with  other  Congressional  directives  in  the  CICA  and  the  1985  DoD 
Authorization  Act,  DoD  should  give  serious  consideration  to  adopting  the  FAR  proposal  rather 
than  the  DoD  FAR  SUPP  proposal.  If  a  few  additional  provisions  are  necessary  to  enable  the 
Defense  Department  to  carry  out  its  special  mission,  DoD  should,  of  course,  be  able  to  supple¬ 
ment  the  FAR  to  accomplish  these  objectives.  Complete  supplantation  of  the  FAR  is,  however, 
neither  necessary  nor  desirable. 
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1.8.1  The  Proposed  DoD  FAR  SUPP  May  Be  Inconsistent  with  the  Proposed  FAR 

The  proposed  DoD  FAR  SUPP  doesn't  even  define  terms  the  same  as  the  proposed  FAR.  For 
example,  the  FAR  definition  of  "unlimited  rights"  is  more  precise  and  comprehensive  than  that 
found  in  the  proposed  DoD  FAR  SUPP.  Other  terms  common  to  both  are  defined  somewhat 
differently  for  no  apparent  reason.  Such  inconsistencies  are  likely  to  result  in  confusion  and 
misinterpretation. 

In  substance,  the  DoD  FAR  SUPP  provisions  are  quite  different  from  the  FAR  provisions.  In 
particular,  the  DoD  FAR  SUPP  fails  to  claim  the  full  set  of  minimum  rights  the  FAR  proposal  says 
that  government  is  supposed  to  acquire  in  restricted  rights  software.  The  failure  of  the  DoD  FAR 
SUPP  to  claim  the  fifth  minimum  right  that  the  FAR  would  allow,  namely  the  right  to  sublicense 
support  contractors,  may  seriously  impede  the  ability  of  DoD  to  obtain  competition  for  main¬ 
tenance  and  enhancement  of  its  software. 


1.8.2  The  Proposed  FAR  Policy  Is  Preferable  to  the  DoD  Policy 

The  proposed  FAR  policy  is  more  comprehensible  than  the  DoD  Policy. 

It  is: 

•  more  concise 

•  more  straightforward 

•  more  consistent  with  commercial  practice 

•  more  consistent  with  intellectual  property  law 

The  proposed  FAR  policy  avoids  the  anomolies  and  inconsistencies  inherent  in  DoD  Policy.  For 
example: 

•  The  FAR  avoids  the  conflict  between  the  DoD  FAR  SUPP  "special  works"  clause  and 
Section  105  of  the  Copyright  Act. 

•  The  FAR,  in  contrast  to  the  DoD  FAR  SUPP,  avoids  the  conflict  between  the  un¬ 
limited  rights  clause  and  the  retention  of  copyright  clause. 

•  The  FAR  avoids  the  confusion  caused  by  the  two  sets  of  restricted  rights  found  in  the 
DoD  FAR  SUPP. 

•  The  FAR  avoids  the  problems  caused  under  the  DoD  FAR  SUPP  by  treating 
software  and  documentation  differently. 

•  The  FAR  avoids  the  problems  caused  by  the  DoD  FAR  SUPP  practice  attaching  two 
different  meanings  to  the  term  "license  rights." 

•  The  FAR  avoids  the  potentially  harsh  result  which  could  occur  from  failure  to 
negotiate  a  separate  licensing  agreement  as  to  restricted  rights  software  under  the 
DoD  FAR  SUPP. 

The  proposed  FAR  provides  a  more  precise  definition  of  "unlimited  rights,"  including  within  this 
definition  the  right  to  make  derivative  works.  This  right  is  important  if  DoD  is  to  be  able  to  main¬ 
tain,  enhance  and  reuse  software.  The  more  limited  definition  of  the  DoD  FAR  SUPP,  in  contrast 
to  the  FAR,  may  be  seen  as  a  rejection  of  this  right  by  the  DoD.  This  could  have  extremely 
serious  repercussions  for  DoD. 
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1.8.3  The  Proposed  FAR  Policy  is  More  Compatible  with  CICA  and  the  1985  DoD 
Authorization  Act  Than  Is  the  DoD  Policy 

The  CICA  and  the  DoD  Authorization  Act  indicate  that  Congress  intended  there  to  be  a  uniform 
system  of  federal  procurement  policy.  The  proposed  DoD  FAR  SUPP  runs  counter,  in  many 
instances,  to  the  policy  which  other  federal  agencies  will  follow  under  the  FAR. 

Congress  intended  that  federal  procurement  regulations  achieve  a  balance  as  to  the  interests  of 
contractors  and  the  government.  The  proposed  FAR  more  reasonably  balances  the  interests  of 
the  parties  involved  than  does  the  DoD  FAR  SUPP.  It,  for  example,  creates  the  potential  for  the 
government  to  take  less  than  unlimited  rights  when  both  public  and  private  funds  are  used  to 
develop  software.  The  proposed  DoD  FAR  SUPP  would  not  permit  this.  In  fact,  the  proposed 
DoD  policy,  while  in  most  respects  the  same  as  the  existing  policy,  would  shift  substantially  the 
rights  balance  in  favor  of  the  government  because  the  definition  of  'developed  at  private 
expense"  would  make  it  nearly  impossible  for  any  software  to  qualify.  This  would  significantly 
reduce  incentives  to  do  business  with  the  government. 

1.9  Conclusion 

An  even  better  solution  to  DoD's  software  data  rights  problems  than  revising  the  standard  data 
rights  clauses  as  suggested  in  Section  1 .7  would  be  for  DoD  to  adopt  the  same  basic  "data 
rights'  policy  as  soon  will  govern  all  other  federal  agency  acquisitions.  More  specifically,  DoD 
should  adopt  the  proposed  Subpart  27.4  of  the  Federal  Acquisition  Regulations  (FAR)  rather  than 
the  proposed  Subpart  27.4  of  the  DoD  FAR  Supplement  (DoD  FAR  SUPP). 

Even  if  DoD  chooses  not  to  adopt  the  FAR  data  rights  provisions,  it  should  recognize  that  the 
current  software  acquisition  policy  is  seriously  flawed  in  a  number  of  respects.  It  is  highly  am¬ 
biguous  about  certain  rights  provisions  concerning  matters  which  need  to  be  clear.  It  conflicts  with 
intellectual  property  law  in  some  instances.  It  creates  needless  disincentives  to  do  business  with 
DoD  in  the  software  acquisition  area.  It  is  not  tailored  to  take  into  account  the  kind  of  technology 
software  is.  The  present  policy  is  too  closely  tied  to  the  technical  data  rights  policy  and  fails  to 
recognize  that  the  economics  of  software  development  are  significantly  different  from  the 
economics  of  technical  data.  If  DoD  wishes  to  acquire  rights  in  the  best  software  technology,  it 
must  adopt  a  software  data  rights  policy  that  is  no  more  divergent  from  standard  commercial 
practices  than  is  essential  to  fulfill  its  mission. 
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2.  Problems  Arising  from  the  Need  to  Maintain  and  Enhance  Software 


Apart  from  the  set  of  software  acquisition  problems  arising  from  the  DoD  procurement  regulations 
discussed  in  Chapter  1 ,  the  next  most  complex  and  difficult  set  of  software  acquisition  problems 
that  were  identified  by  DoD  personnel  in  the  course  of  our  investigation  related  to  the  main¬ 
tenance  and  enhancement  of  software.  Software  often  requires  some  modification  to  correct 
"bugs”  or  other  deficiencies  which  may  not  be  discovered  until  after  the  software  has  been  ac¬ 
quired,  and  perhaps  even  after  it  has  been  embedded  in  a  larger  system.  In  addition,  the  user 
may  want  to  have  software  modified  so  as  to  add  some  new  capability  or  function  beyond  that 
which  the  product  was  originally  intended  to  perform,  or  to  upgrade  the  software  when  new  tech¬ 
nological  developments  are  achieved.  (Problems  relating  to  these  sorts  of  modifications  will 
hereinafter  be  referred  to  as  ’maintenance/enhancement”  problems.) 

The  adaptability  of  software  over  time  is  one  of  the  great  advantages  of  software  as  compared 
with  hardware,  but  adaptability  is  not  an  unmixed  blessing.  Along  with  adaptability  comes  a 
complex  set  of  licensing  problems  that  have  frustrated  DoD  personnel  as  they  have  sought  to 
acquire  excellent  adaptable  software  at  the  lowest  cost.  One  set  of  these  problems  arises  from 
the  debate  within  DoD  over  whether  it  is  wise  or  cost-effective  to  compete  the  maintenance  or 
enhancement  of  software  to  third  party  contractors,  or  even  to  do  maintenance/enhancement 
work  in-house. 

The  first  four  sections  of  this  chapter  discuss  the  licensing  aspects  of  this  controversy  and  recom¬ 
mend  some  strategies  for  how  DoD  might  compete  software  maintenance  if  it  chooses  to  do  so. 
The  chapter  also  discusses  some  of  the  disadvantages  of  competing  software  maintenance.  The 
remaining  two  sections  of  the  chapter  discuss  a  variety  of  other  problems  identified  by  DoD 
personnel  as  software  maintenance/enhancement  problems.  One  of  the  reasons  software 
maintenance/enhancement  problems  may  seem  intractable  is  that  they  are  not  one  but  many 
problems.  There  is  no  quick  fix  that  will  solve  all  of  them  at  once. 

2.1  Getting  Sufficient  Rights  In  or  Documentation  about  Software  to  Enable 
DoD  to  Do  "Organic"  or  Competitive  Maintenance  or  Enhancement  for 
Software 

The  initial  statement  of  work  for  the  Software  Licensing  Project  (as  reflected  in  the  SEI  RFP) 
indicated  that  DoD  had  been  having  trouble  acquiring  sufficient  rights  in  software  and  software 
documentation  to  enable  it  to  maintain  or  enhance  software,  either  in-house  (commonly  referred 
to  as  "organic  maintenance")  or  by  private  firms  through  competitive  bidding.  DoD  sought  assis¬ 
tance  in  solution  of  these  problems. 


2.1 .1  Getting  Rights  to  Modify 

Obtaining  rights  for  the  government  to  modify  software  is  not  a  current  software  licensing  problem 
of  the  Defense  Department.  While  many  other  buyers  or  licensees  of  software  are  experiencing 
difficulty  in  negotiating  with  software  firms  about  whether  or  not  they  can  modify  software,  this 
does  not  seem  to  be  DoD’s  problem.  The  DoD  procurement  regulations  require  that  in  all 
software  acquisition  contracts  the  government  must  get  the  right  to  modify  the  software  ( [61]  sec. 
52 . 227-70 1 3(b) (3)) .  Government  lawyers,  on  the  whole,  tend  to  think  that  this  means  that  even 
when  a  contract  between  the  government  and  a  software  contractor  is  silent  about  modification 
rights,  the  standard  data  rights  clause  will  be  construed  by  a  court  to  be  incorporated  into  the 
contract  under  the  Christian  doctrine.  (See  [29])  in  which  the  court  read  a  "termination  for  the 
convenience  of  the  government"  clause  into  a  military  housing  contract.)  On  the  other  hand, 
some  DoD  contract  officers  seemed  to  believe  that  if  prime  contractors  had  negotiated  away  the 
government's  right  to  modify  software  in  dealing  with  a  subcontractor,  the  government  would  be 
bound  by  the  prime's  action.  This  may  not  in  fact  be  so  for  reasons  discussed,  at  Chapter  8. 

If,  instead  of  relying  on  the  DoD  standard  data  rights  clause,  the  government  was  relying  on  the 
copyright  law  as  a  basis  for  obtaining  rights  to  modify  software,  the  government's  rights  would  be 
on  more  shaky  grounds.  Copyright  law  regards  any  modification  of  copyrighted  software  as  the 
creation  of  a  "derivative  work"  which  one  needs  permission  of  the  copyright  owner  to  do  ( [59] 
sec.  106(2)).  Although  owners  of  copies  of  software  have  a  limited  right  to  modify  software  under 
Section  117  of  the  copyright  law,  the  right  is  so  limited  as  to  be  virtually  nonexistent  (1)  because 
only  " owners’  of  copies  ( and  seemingly  not  licensees)  have  such  rights,  and  (2)  because 
modifications  are  only  permitted  to  the  extent  they  are  created  as  an  "essential  step  in  the  utiliza¬ 
tion  of  a  computer  program  in  conjunction  with  a  machine."  One  court  has  interpreted  this  to 
mean  that  modifications  are  only  permitted  if  the  program  won’t  execute  as  is  (Midway  Mfg.  Co.  v. 
Strohon  [38]).  Because  copyright  law  currently  offers  such  limited  rights  to  modify  software,  it  is  a 
good  thing  for  DoD  that  it  has  made  modification  rights  part  of  the  package  of  minimum  rights  that 
it  always  gets  in  software. 

2.1 .2  Getting  Adequate  Documentation  to  Make  Modifications 

Getting  adequate  software  documentation  seems  to  be  the  major  software 
maintenance/enhancement  problem  experienced  by  the  Defense  Department.  Many  of  the 
"horror  stories"  we  heard  were  instances  of  one  of  the  following  sorts: 

(a)  not  being  farsighted  enough  to  ask  for  delivery  of  all  the  documentation  needed  to  en¬ 
hance  or  maintain  a  system  (by  tar  the  most  common  and  most  significant  problem); 

(b)  not  being  sufficiently  diligent  in  supervising  the  delivery  of  documentation  to  insure  that 
everything  that  should  have  been  delivered  was,  in  fact,  delivered; 

(c)  not  supervising  the  attachment  of  restrictive  notices  to  software  to  ensure  they  were  only 
attached  to  software  wholly  developed  at  private  expense; 

(d)  not  being  able  to  comprehend  the  documentation  delivered  because  of  its  complexity  or 
turgidity;  or 
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(a)  companies  being  unwilling  to  give  their  source  code  to  the  government  at  any  price  or 
under  any  conditions. 

There  was  general  agreement  among  DoD  persons  to  whom  we  spoke  that  steps  needed  to  be 
taken  to  remedy  this  situation.  Some  were  hopeful  that  solutions  could  be  devised  that  would 
create  greater  incentives  for  industry  to  voluntarily  cooperate  with  DoD  in  its  efforts  to  get  better 
documentation  for  maintenance  purposes.  Some  worry  that  punitive  approaches  would  enhance 
already  strong  disincentives  to  cooperate  with  the  government  in  this  respect. 

2.1.3  Getting  Sufficient  Rights  in  Software  and  Documentation  to  Get  Competition 
as  to  Software  Maintenance  and  Enhancements 

Whether  the  government  can  get  competition  in  software  maintenance  and  enhancement  con¬ 
tracts  seems  largely  to  turn  on  whether  the  government  has  ownership  of  or  unlimited  rights  in 
software  and  its  associated  documentation,  or  whether  the  government  has  only  restricted  rights 
as  to  the  software  and  limited  rights  as  to  the  documentation.  If  the  government  has  ownership  or 
unlimited  rights,  getting  competition  in  software  maintenance/enhancement  contracts  is  said  to  be 
easy.  If  instead  the  government  has  only  restricted  and  limited  rights,  it  seems  that  getting 
competition  is  very  difficult.  Defense  Department  personnel  generally  report  little  success  in 
getting  "proprietary*  software  competitively  maintained. 

As  the  DoD  regulations  are  presently  written,  while  DoD  virtually  always  has  rights  to  modify  the 
software,  the  regulations  do  not  provide  DoD  with  the  rights  necessary  to  sublicense  the  modifica¬ 
tion  right  to  others.  Such  a  right  must  be  specifically  negotiated.  That  means  that  getting  com¬ 
petition  as  to  maintenance  and  enhancement  of  restricted  rights  software  will  only  be  feasible  if 
the  software's  owner  will  agree,  which  he  need  not.  If  he  will  not  agree,  DoD  will  either  have  to 
do  the  modifications  itself  or  hire  the  original  firm  to  do  the  maintenance  on  a  sole  source  basis. 
Because  many  software  companies  may  wish  to  have  sole  source  maintenance  contracts  with 
DoD,  their  incentives  to  agree  to  competitive  maintenance  are  minimal.  The  critical  point  is  that 
the  only  time  there  may  be  any  opportunity  to  get  such  agreements  to  allow  competitive  main¬ 
tenance  is  during  the  original  competition  when  the  development  contract  is  let. 

2.2  Maintenance  Needs  for  Things  Used  in  Performance  of  Government 
Contracts:  Software  Tools  and  CAD/CAM  Programs 

Documentation  may  not  be  the  only  thing  which  may  be  needed  in  order  to  maintain  or  enhance 
software  and  the  systems  of  which  they  may  be  a  part.  Access  to  software  tools  or  CAD/CAM 
programs  which  a  firm  may  have  employed  in  developing  the  system  may  also  be  needed.  In¬ 
dustry  is  likely  to  be  even  more  sensitive  when  the  government  expresses  its  interest  in  obtaining 
such  tools  or  CAD/CAM  systems  for  maintenance  and  enhancement  purposes  than  it  would  be 
about  the  government  obtaining  software  documentation,  especially  if  the  government  seeks  to 
obtain  such  things  for  competitive  maintenance  purposes. 


2.2.1  Software  Tools 

Software  tools  are  a  set  of  programs  that  may  be  used  to  produce  other  programs.  Software 
tools  commonly  include  editors,  compilers,  and  debuggers,  among  other  things.  The  application 
software  produced  by  the  tools  could  be  anything  from  the  guidance  system  of  a  missile  to  an 
inventory  control  program.  Much  of  the  expensive  software  the  government  buys  is  software 
which  is  expected  to  be  modified  over  time.  For  example,  satellite  monitoring  systems  must  be 
revised  whenever  a  new  satellite  is  launched.  In  order  to  modify  application  software  in  an 
optimal  way  -and  in  some  cases,  in  order  to  modify  it  at  all  -  it  may  be  desirable  or  necessary  to 
have  access  to  the  tools  that  were  used  to  create  the  program  in  the  first  place.  Even  if  the 
government's  contract  officers  have  the  foresight  to  try  to  bargain  to  obtain  rights  in  software 
tools,  the  company  may  be  extremely  reluctant  to  grant  anyone  -  let  alone  the  government 
(which  is  widely  perceived  by  industry  to  be  unable  to  protect  commercial  secrets)  -  to  have  a 
copy  of  the  software  tools,  or  even  to  have  access  to  the  tools.  A  software  producer's  tools  may 
be  perceived  to  be  the  major  factor  in  the  company's  competitive  edge  in  the  industry.  Parting 
with  them  may  be  a  highly  charged  subject.  Indeed,  for  the  government  to  be  able  to  make  any 
deal  to  get  proprietary  software  tools  is  thought  a  remarkable  event. 

One  potential  approach  to  solving  this  problem  might  be  for  non-governmental  third  parties  to 
enter  into  licensing  arrangements  with  the  software  tool  producer  (assuming  that  the  company 
would  license  anyone)  on  more  restrictive  terms  than  government  procurement  practices  would 
allow.  The  government  could  then  allow  this  third  party  licensee  to  do  the 
maintenance/enhancement  work.  This  may  not  be  a  solution  in  all  instances,  however. 

There  seems  to  be  a  strong  preference,  if  not  a  clear  policy,  for  DoD  to  do  "organic" 
maintenance/enhancement  work  for  all  weapons  system  software  and  weapon  related  software. 
We  were  also  frequently  told  that  many  companies  would  not  license  proprietary  software  tools  to 
anyone. 

Those  software  tools  which  companies  are  likely  to  be  willing  to  make  available  to  the  govern¬ 
ment  with  unlimited  rights  are  the  older,  less  valuable  technologies.  If  DoD’s  priority  is  to  get  the 
best  technology,  using  old  tools  doesn’t  seem  to  be  desirable.  If  DoD's  priority  is  to  be  able  to  do 
all  maintenance  and  enhancement  organically  or  competitively,  then  having  rights  to  old  tools  is 
better  than  having  rights  in  none. 
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2.2.2  CAD/CAM  Programs 

Increasingly,  industries  are  using  computer  aided  desigrVcomputer  aided  manufacturing 
(CAD/CAM)  programs  to  design  and  manufacture  systems.  Most  of  the  examples  we  heard 
concerning  systems  designed  for  the  government  with  CAD/CAM  programs  were  from  the 
aerospace  industry.  Because  aircraft  tend  to  be  rather  expensive  systems  and  systems  which 
require  more  than  a  modest  amount  of  maintenance  and  enhancement,  both  as  to  software  and 
hardware  components,  there  is  growing  concern  within  the  Defense  Department  about  getting 
access  to  and  rights  in  the  CAD/CAM  programs  used  to  design  the  systems  in  the  first  place.  V 
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These  programs  may  be  essential  to  do  maintenance  and  enhancement  work  for  the  system.  i 

Chapter  10  discusses  the  CAD/CAM  problem  at  somewhat  greater  length,  but  because  the  I 

government’s  need  for  CAD/CAM  programs  largely  centers  on  maintenance  needs,  it  seemed  j 

necessary  to  flag  the  issue  in  the  maintenance  section  as  well.  ! 

I 

As  with  the  software  tool  problem,  the  CAD/CAM  problem  is  one  about  which  the  industry  is  j 

extremely  sensitive,  and  one  for  which,  as  a  consequence,  it  may  be  difficult  to  find  a  compromise  | 

solution  that  will  be  acceptable  to  both  the  government  and  industry. 

2.3  Structural  Problems  with  Getting  Delivery  of  Adequately  Supportable 
Systems 

2.3.1  Different  Interests  of  Buyers  and  Maintainers  within  the  Government 

There  appear  to  be  some  structural  problems  internal  to  the  Defense  Department  that  may  make 
adequate  planning  for  software  maintenance  and  enhancement  difficult  to  achieve.  Major 
weapons  or  communication  systems  acquired  by  DoD  may  include  complex  software  com¬ 
ponents.  These  systems  may  also  require  significant  and  complex  software  systems  to  support 
the  major  systems.  If  the  command  which  purchases  the  system  is  not  the  command  which  will 
use,  maintain,  or  enhance  the  system,  it  may  not  be  aware  of  the  extent  of  software  documen¬ 
tation  that  will  be  needed  to  use,  enhance,  or  maintain  the  software,  and  it  may  not  be  as  sen¬ 
sitive  to  the  need  for  supportability  software  as  the  using  or  maintaining  command  might  need  it 
to  be.  Although  there  are  some  structural  mechanisms  within  DoD  that  are  intended  to  provide 
opportunities  for  communications  about  such  matters,  they  do  not  seem  to  be  working  as  suc¬ 
cessfully  as  DoD  may  wish.  This  is  seen  by  many  to  be  a  contributing  cause  toward  the  software 
maintenance  and  enhancement  problems  DoD  has  encountered  down  the  line. 

2.3.2  Sole  Source  Maintenance  as  a  Habit 

From  procurement  personnel's  point  of  view,  if  a  company  has  built  a  complex  piece  of  software 
for  DoD,  and  it's  a  good  piece  of  software,  that  company  will  know  that  software  better  and  will  be 
able  to  maintain  it  better  than  any  other  company,  even  if  the  other  company  gets  the  source 
code.  That  software  engineering  is  still  in  fairty  primitive  stages  as  an  engineering  discipline 
makes  reliance  on  the  original  developer  to  do  maintenance  work  seem  the  most  expedient  route 
to  take.  The  developing  company  will  have  a  better  idea  of  how  to  avoid  the  problems  that 
enhancing  software  so  often  creates  for  another  part  of  code.  Theoretically,  the  developing  firm 
will  be  able  to  do  the  job  faster,  more  reliably,  and  more  cheaply  than  a  competitor.  And  if  it's  a 
good  piece  of  code,  then  the  developing  company  may  be  thought  to  deserve  to  reap  some  more 
rewards  for  it.  Besides,  procurement  personnel  may  be  wont  to  think,  we  already  know  these 
guys  and  they  do  a  good  job  for  us.  Quality  and  quickness  count  for  something;  money  isn’t 
everything.  So  why  not  deal  with  that  company  instead  of  having  to  go  through  a  long  drawn  out 
competition  process? 
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Over  time,  the  original  developer  may  become  more  and  more  confident  of  its  position  as  the  sole 
source  for  maintenance  of  software,  and  may  increase  the  price  for  its  services  accordingly.  It 
may  be  aifficutt  for  the  government  to  break  away  from  sole  source  maintenances  no  matter  what 
the  cost.  It  should  be  noted  that  commercial  buyers  tend  to  have  similar  difficulties  in  this 
respect. 

2.3.3  Lack  of  Experience  and  Training  as  Contributors  to  the  Problems 

If  one  adds  to  this  set  of  already  descrfred  structural  disincentives  to  adequate  planning  for 
software  maintenance  and  supportability,  the  fact  that  procurement  personnel  are  often  not  well 
trained  about  software,  system  lifecycles,  or  data  rights,  one  can  see  that  the  structural  problems 
internal  to  the  Defense  Department  may  be  significant  contributors  to  software  maintenance 
problems.  It  takes  considerable  sophistication  and  experience  with  major  systems  and  what  it 
takes  to  support  them  to  plan  ahead  for  system  supportability.  Adequate  planning  may  be  made 
additionally  difficult  because  at  the  time  a  development  contract  may  be  let,  the  software  for  the 
system  may  not  yet  be  in  existence,  but  only  in  the  preliminary  planning  stages,  and  supportability 
of  the  software  system  may  not  be  easily  plannable  until  after  the  system  is  more  fully  developed. 

2.3.4  How  Internal  Structural  Problems  Work  to  the  Advantage  of  Industry 

It  is  perhaps  an  obvious  point  that  the  structural  problems  internal  to  the  Defense  Department 
create  opportunities  in  software  maintenance  and  supportability  contexts  for  industry  to  charge 
very  large  sums  of  money  for  work  or  rights  that  could  have  been  purchased  more  cheaply  had 
they  been  bargained  for  at  the  earty  phases  of  the  contractual  arrangement.  It  is  often  in  the 
industry's  interest  to  take  advantage  of  these  opportunities  when  they  arise. 

2.4  Recommendations  about  How  to  Plan  Better  for  Maintenance  and 
Enhancement  of  Software 

Although  further  work  could  surely  be  done  about  the  government’s  software  maintenance  licens¬ 
ing  problems  discussed  thus  far,  it  is  possible  to  identify  some  ways  in  which  DoD  might  improve 
its  approach  to  solving  this  class  of  maintenance/enhancement  problems.  New  regulations  won't 
help  much.  The  best  solution  to  this  class  of  problems  is  improved  planning  for  maintenance  and 
enhancement  of  software  at  the  time  the  contract  is  made. 

2.4.1  Getting  Adequate  Documentation  to  Enable  Maintenance  or  Enhancements 

(a)  DoD  would  do  well  to  develop  a  better,  more  standardized  set  of  specifications  about  what 
software  documentation  must  be  delivered  to  DoD  and  with  what  rights. 

(b)  DoD  should  decide  upfront  what  arrangements  the  government  wants  or  needs  to  make 
about  who  should  do  the  maintenance  or  enhancement  work.  For  reasons  other  than  merely 
cost,  the  government  may  need  to  do  the  maintenance  in-house.  How  much  rights  and  how 
much  data  the  government  needs  from  a  contractor  will  in  large  measure  depend  on  this  decision. 


(c)  DoD  should  assess  the  relative  costs  of  acquiring  different  levels  of  rights  and  of  sole 
source,  internal,  or  competitive  maintenance  over  time  so  that  cost-effective  choices  can  be  made 
upfront.  DoD  should  recognize  that  sometimes  sole  source  maintenance  will  be  cheaper  than 
acquiring  all  the  rights  and  data  needed  to  do  the  maintenance  in-house. 

(d)  DoD  should  insist  that  its  procurement  personnel  involve  both  the  using  command  and  the 
maintaining  command  in  the  supportability  planning,  perhaps  even  getting  engineers  from  these 
latter  commands  to  sign  off  on  the  system. 

(e)  DoD  should  train  contracting  personnel  about  software  life  cycle  needs,  about  data  rights, 
and  about  software  documentation  as  regards  supportability  needs.  (See  Chapter  3.) 

(f)  DoD  should  consider  entering  into  escrow  arrangements  whereby  documentation  may  be 
placed  in  the  hands  of  a  third  party,  such  that  upon  the  happening  of  certain  contingencies,  the 
documentation  will  be  released  to  the  government  for  maintenance  purposes.  This  would  assure 
that  until  the  happening  of  this  contingency,  the  industry's  valuable  software  documentation  will 
be  protected  from  disclosure,  while  at  the  same  time  assuring  that  the  government  can  get  ac¬ 
cess  to  it  under  specified  conditions. 

2.4.2  Getting  Sufficient  Rights  to  Enable  Competition  for  Maintenance 

(a)  DoD  should  recognize  that  it  may  be  difficult  or  impossible  to  compete  maintenance  and 
enhancement  of  software  held  as  a  trade  secret  by  its  owner.  DoD  needs  to  assess,  to  the  extent 
it  can,  what  the  long  term  maintenance  needs  and  costs  are  likely  to  be,  taking  into  account  what 
cost  savings  may  be  achievable  by  competition.  It  may  not  be  worthwhile  to  buy  rights  to  com¬ 
pete  maintenance. 

(b)  DoD’s  best  chance  to  get  competition  as  to  software  maintenance  will  be  when  it  is  initially 
negotiating  the  system’s  development  contract. 

(c)  If  DoD  decides  to  try  to  compete  the  maintenance,  it  must  recognize  that  it  will  need  to  get 
upfront: 

(i)  the  ability  to  sublicense  Its  software  modification  right  or  a  commitment  by  the  contractor  to 
license  another  company  to  modify  the  software; 

(ii)  the  ability  to  sublicense  the  documentation  about  the  software,  or  a  commitment  by  the 
contractor  to  license  the  other  company  to  have  access  to  the  documentation; 

(iii)  very  detailed  documentation;  and  possibly 

(iv)  rights  in  the  software  tools,  or  a  commitment  from  the  developing  firm  to  license  a 
competitor's  access  to  the  tools. 

(d)  It  may  be  desirable  for  DoD  to  develop  a  standard  competitive  reprocurement  or  main¬ 
tenance  license  provision  and  clause  for  the  DoD  FAR  SUPP  in  order  to  alert  contract  officers  to 
the  need  for  and  the  appropriate  manner  of  obtaining  rights  for  these  purposes. 
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(e)  To  be  able  to  maximize  the  possibility  of  gaining  agreement  for  competitive  maintenance  of 
proprietary  software,  DoD  should  be  prepared  to  make  arrangements  : 

(i)  either  to  name  who  will  be  the  third  party  maintainer  or  define  what  process  will  be  used  to 
qualify  a  potential  third  party  maintainer;  and 

(ii)  to  promise  the  developer  of  the  software  to  put  the  competitive  maintainer  under  a  specific 
set  of  restrictions  (such  as  those  under  which  the  government  operates  as  to  that  software). 

The  government  might  also  want  to  consider  naming  the  original  software  developer  as  a  third 
party  beneficiary  of  the  agreement  between  the  government  and  the  third  party  maintainer  as  to 
restrictions  on  rights  so  that  if  there  is  abuse,  the  developer  can  sue  the  maintainer  directly. 

2.5  Other  Legal  Issues  Relating  to  Modifications 

Although  the  government  clearly  has  the  right  to  modify  software  developed  at  private  expense,  a 
number  of  legal  questions  have  been  raised  about  modifications,  some  of  which  derive  from  the 
DoD  regulations  and  some  from  copyright  law. 

2.5.1  Questions  under  the  DoD  FAR  SUPP 
Unlimited  Rights  and  Derivative  Works  Rights 

An  important  question  that  affects  its  rights  to  modify  and  enhance  software  developed  at  public 
expense  --  a  question  to  which  the  DoD  regulations  give  no  answer  -  is  whether  the  Defense 
Department  has  the  right  to  prepare  derivative  software.  The  definition  of  unlimited  rights  makes 
no  mention  of  a  derivative  works  right.  It  should  if  DoD  wants  to  be  sure  it  has  one. 

Effect  of  Modification  on  Pre-existing  Restrictions 

If  DoD  modifies  proprietary  software  in  which  it  has  only  restricted  rights,  how  does  the  modifica¬ 
tion  affect  the  restrictions?  The  standard  data  rights  clause  ( [61]  sec.  52.227-7013)  seems  to 
answer  the  question  somewhat  differently,  depending  on  what  kind  of  restricted  rights  software 
one  is  talking  about.  It  provides  as  to  commercial  software  (or  rather  to  software  that  a  firm  has 
elected  to  have  treated  as  commercial  software)  that  ’unmodified  portions  [of  the  restricted  rights 
commercial  software]  shall  remain  subject  to  these  restrictions.’  (See  subsection  (b)(3)(H).)  Other 
than  commercial  software  is  governed  by  subsection  (b)(3)(i)  which  refers  the  reader  back  to  the 
definition  of  restricted  rights  in  subsection  (a),  which  in  its  subsection  (4)  provides  that  “those 
portions  of  the  derivative  software  incorporating  restricted  rights  software  are  subject  to  the  same 
restricted  rights.’ 

It  may  be  that  the  intent  of  the  drafters  of  this  clause  was  for  these  two  provisions  to  mean  the 
same  thing.  If  that  is  so,  it  is  a  shame  that  precisely  the  same  wording  wasn't  used  in  both 
places,  for  that  would  remove  the  potential  for  ambiguity.  If  they  were  intended  to  mean  different 
things,  it  is  not  clear  why  this  would  be  so.  Several  lawyers  to  whom  we  spoke  thought  that  these 
provisions  were  not  substantively  the  same  and  believed  the  commercial  software  provision  to  be 
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less  generous  to  industry  than  the  other  provision.  Others  were  utterly  baffled  by  this  inconsis¬ 
tency. 

Restrictions  Attaching  to  Modified  Portions 

Several  lawyers  -  some  from  government,  some  from  industry  --  raised  the  question  of  how  DoD 
would  treat  those  portions  of  the  software  that  were  modified.  Who  would  ’own"  the  rights  in 
them?  What,  if  any,  restrictions  might  they  be  subject  to?  The  DoD  regulations  are  not  clear 
about  this  (except  perhaps  as  to  modifications  of  unlimited  rights  software,  for  which  DoD  FAR 
SUPP  sec.  27.404-1  (a)(4)  says  the  government  will  have  unlimited  rights  to  changes  in  things  in 
which  they  already  have  unlimited  rights.)  In  the  absence  of  clear  guidance  from  the  regulations, 
most  of  those  who  have  thought  about  the  question  have  assumed  that  the  government  would 
have  unlimited  rights  in  all  modifications,  whether  done  by  the  government  or  a  private  firm. 
Because  of  the  problems  arising  from  the  copyright  retention  provisions  of  the  DoD  FAR  SUPP 
and  because  of  certain  provisions  of  the  copyright  law,  which  may  have  a  bearing  on  rights  in 
these  circumstances,  it  is  not  clear  that  this  assumption  is  entirely  correct  (see  subsection  2.1 .2 
and  Chapter  4). 

Duty  Not  to  Prepare  Similar  Software 

The  DoD  regulations  provide  that  when  software  has  been  delivered  at  private  expense  and 
acquired  by  the  government  with  restricted  rights,  the  associated  documentation  will  not  be  used 
to  prepare  similar  software  ([61]  sec.  27.404-1  (e)).  Some  have  thought  this  may  have  some 
limiting  effect  on  the  government's  rights  to  modify  software. 

Reverse  Engineering 

If  the  government  has  not  obtained  sufficient  documentation  in  software  to  enable  it  to  modify  the 
software  easily  and  if  either  there  is  not  time  to  get  the  original  contractor  to  modify  it,  or  the 
contractor  wants  an  unreasonable  sum  for  the  modification,  government  personnel  may  try  to 
reverse  engineer  the  software  to  figure  out  what  needs  to  be  fixed. 

Reverse  engineering  will  very  likely  involve  making  a  copy  of  the  program  for  reverse  engineering 
purposes.  An  interesting  question  is  whether  the  making  of  such  a  copy  is  authorized  under  the 
restricted  rights  provisions  of  the  standard  data  rights  clause.  Those  provisions  seem  to  limit  the 
right  to  copy  software  to  archival  or  back  up  purposes  ( [61],  sec.  52.227-70 13(a)  and  (b)(3)).  Of 
course,  the  government  might  argue  that  since  it  is  often  necessary  to  make  a  copy  of  the 
software  in  order  to  be  able  to  figure  out  how  to  modify  it,  it  is  impliedly  within  its  modification 
rights.  Software  firms,  of  course,  might  read  the  provision  more  literally,  and  argue  that  modifying 
the  code  is  all  the  government  has  bought  rights  to  under  the  data  rights  clause. 


2.5.2  Questions  Under  Copyright  Law 
Reverse  Engineering 

Apart  from  the  DoD  regulations,  might  DoD  be  able  to  rely  on  the  copyright  law  to  obtain  rights  to 
reverse  engineer  software?  The  answer,  at  least  currently,  would  seem  to  be  it  doesn't  look  so 
good.  A  recent  software  copyright  infringement  case  held  that  making  a  copy  (including  making  a 
core  dump  of  the  code  into  printed  I's  and  O’s  of  a  program  for  reverse  engineering  purposes) 
was  an  infringement  of  the  copyright,  notwithstanding  that  the  parties  charged  with  infringement 
had  lawfully  obtained  a  copy  of  the  software  (Hubco  Data  Products  Corp.  v.  Management  Assis¬ 
tance,  Inc.  [31]).  While  there  are  some  copyright  scholars  who  would  argue  that  reverse  en¬ 
gineering  ought  to  be  permissible  in  software  cases  as  a  matter  of  copyright  law,  this  precedent 
stands  for  the  contrary  proposition.  Any  prudent  user  of  software  ought  to  be  aware  of  the  legal 
risks  he  or  she  is  taking  if  any  copy  of  the  software  is  made  in  the  process  of  reverse  engineering 
the  software. 

Ownership  Rights  In  Modifications 

The  unclarity  of  the  DoD  regulations  about  ownership  rights  and  restrictions  as  to  software 
modifications  may  mean  that  if  the  original  software  is  claimed  to  be  protected  under  copyright 
law  (even  as  an  unpublished  work),  it  is  copyright  law  that  will  fill  in  the  gaps.  The  general 
principle  of  copyright  law  is  to  assign  ownership  rights  to  whoever  is  the  'author*  of  an  'original 
work.’  Creation  of  a  derivative  work  may  involve  original  authorship.  (Even  an  edited  work  will 
involve  the  editor's  judgment  about  what  to  include  and  what  to  leave  out.  Even  the  translation  of 
a  book  from  one  language  to  another  involves  selecting  this  adjective  instead  of  its  synonym  for 
incorporation  into  the  translation.)  Modifications  of  software  are  derivative  works  that  may  qualify 
for  some  copyright  protection. 

However,  unless  one  has  the  permission  of  a  copyright  owner  from  whose  work  one's  own  work 
derives  to  make  such  a  derivative  work,  one  infringes  the  copyright.  If  the  original  author  has 
given  a  second  author  only  limited  permission  to  make  the  derivative  work  (e  g.,  only  for  a  par¬ 
ticular  purpose)  the  latter's  ownership  rights  may  be  curtailed  to  that  extent.  As  Chapter  4  ex¬ 
plains,  copyright  protection  will  not  be  afforded  to  any  unauthorized  derivative  work  to  the  extent  it 
incorporates  the  original  work's  expression.  It  will  also  not  be  given  to  a  derivative  work  au¬ 
thorized  for  a  limited  purpose  and  then  used  beyond  the  original  puqpose  ([59]  sec.  103(a)). 
(See  also  Chapter  7  for  an  elaboration  on  this  point.) 

It  is  probably  also  worth  mentioning  that  the  government  would  not  likely  be  free  from  obligations 
to  the  owner  of  proprietary  software  simply  because  at  some  point  the  government’s  enhance¬ 
ments  would  be  substantial  enough  to  make  the  proprietary  software  unrecognizable. 

To  the  extent  that  the  government  has  a  firm  other  than  the  copyright  owner  do  maintenance  or 
enhancement  work  for  it,  the  government  ought  to  recognize  that  the  maintenance/enhancement 
firm  may  claim  rights  to  the  enhancements  (It  may  even  deliver  the  enhanced  version  with  its 
copyright  notice)  but  the  viability  of  these  rights  claims  would  be  limited  by  the  scope  of  authoriza¬ 
tion  DoD  has  from  the  original  contractor. 
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2.6  Other  Software  Maintenance/Enhancement  Licensing  Problems 

2.6.1  Effect  on  Warranties  When  Software  Is  Modified 

Much  of  the  software  available  commercially,  and  much  of  the  software  developed  for  DoD,  is 
unwarranted  software,  that  is,  software  delivered  under  contracts  which  disclaim  liability  for 
defects.  One  DoD  lawyer  complained  to  us  that  often  the  nearest  thing  to  a  warranty  the  govern¬ 
ment  can  negotiate  for  as  to  software  is  a  promise  from  the  contractor  to  take  a  look  at  the 
software  and  try  to  fix  it  if  problems  later  arise.  Increasingly,  however,  the  government  has  been 
able  to  negotiate  warranties  for  software  systems,  and  perceives  itself  to  need  warranties.  As 
reluctant  as  firms  may  be  to  warrant  software,  their  willingness  to  negotiate  warranties  may 
depend  on  whether  they  will  get  the  contract  to  do  all  the  maintenance/enhancement  work  or 
whether  the  government  plans  to  do  the  maintenance  itself  or  compete  the  maintenance.  Be¬ 
cause  enhancements  to  software  will  sometimes  adversely  affect  the  functioning  of  the  un¬ 
modified  portions  of  the  code,  software  producers  have  legitimate  concerns  about  what  might  be 
done  to  any  software  they  have  warranted,  but  which  they  are  precluded  from  maintaining.  In 
making  licensing  arrangements,  the  government  may  have  to  trade  getting  a  warranty  in  software 
for  getting  maintenance  competition.  Indeed,  a  contractor  will  generally  include  a  clause  provid¬ 
ing  that  modifications  to  the  software  will  void  the  warranty. 


2.6.2  Configuration  Management 

The  Air  Force,  in  particular,  reports  having  some  difficulty  in  managing  the  large  volume  of  infor¬ 
mation  about  software  and  all  its  many  versions  that  may  be  necessary  to  have  in  order  to  do 
maintenance/enhancement  work  organically  or  to  contract  out  for  such  services.  This  seems  to 
be  due,  in  part,  to  resource  constraints  (personnel,  expertise,  and  equipment)  and  in  part,  to 
having  "old"  information.  Delays  caused  by  bureaucratic  procedures  that  must  be  followed  to 
accomplish  a  change  in  the  configuration  are  reportedly  also  a  serious  problem.  Sometimes,  Air 
Force  personnel  said,  the  Air  Force  takes  delivery  of  software  documentation  at  an  early  stage, 
following  which  some  substantial  modifications  of  the  software  are  be  made  by  the  developer, 
about  which  the  government  may  not  have  or  get  full  documentation.  In  some  cases,  we  were 
told,  this  was  a  problem  of  not  having  arranged  for  delivery  of  later  developed  material,  and  in 
some  cases,  of  not  following  up  on  getting  delivery  of  the  needed  material.  Several  of  the  Air 
Force  people  with  whom  we  spoke  about  this  matter  favored  the  idea  of  having  the  developer  do 
configuration  management  for  Air  Force  software  on  the  theory  that  it  would  be  done  better  by 
industry  than  by  the  government. 

2.6.3  Insertion  of  Proprietary  Modules  into  Unlimited  Rights  Software 

We  were  told  that  firms  that  do  software  enhancement  work  on  software  in  which  DoD  has  un¬ 
limited  rights  have  on  occasion  delivered  back  to  the  government  software  into  which  the  com¬ 
panies  have  inserted  proprietary  modules. 
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2.6.4  Use  of  Unusual  Computer  Languages  or  Equipment  to  Get  into  Sole  Source 
Maintenance  Arrangements 

We  heard  of  several  examples  of  contractors  using  nonstandard  programming  languages  and 
equipment  to  prepare  software  for  delivery  to  the  government.  DoD  personnel  to  whom  we  spoke 
seemed  to  believe  that  a  primary  motivation  for  this  was  in  order  to  facilitate  being  in  a  sole 
source  maintenance  position. 

2.6.5  Indemnification  if  Third  Party  Software  Maintainer  Abuses  Rights 

Many  government  lawyers  were  very  concerned  about  whether  the  government  would  be  liable  if 
a  firm  to  whom  the  government  provided  proprietary  software  and  its  associated  documentation 
for  the  limited  purpose  of  doing  maintenance  or  enhancement  work  abused  the  right  to  have  this 
material,  for  example,  using  it  to  prepare  a  competitive  product.  Some  persons  in  the  Defense 
Department  believed  it  appropriate  for  the  government  to  assume  responsibility  for  this.  Others 
were  adamant  that  the  government  should  not  be  liable. 
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3.  The  Need  for  Better  Training  about  Software,  Data  Rights,  and 
Intellectual  Property  Law 


Chapter  1  has  elucidated  the  many  complexities  that  the  Defense  Department's  standard  data 
rights  policy  entails,  as  well  as  the  necessary  and  complex  interaction  of  intellectual  property  law 
and  the  data  rights  regulations.  Chapter  2  has  observed  that  software  development  contracts 
involve  acquiring  not  only  rights  in  software,  but  acquiring  a  substantial  volume  of  documentation 
that  may  be  needed  to  maintain  or  enhance  the  software.  To  do  this  job  welt,  DoD’s  procurement 
personnel  need  to  have  considerable  expertise  about  software  as  a  technology,  about  software 
life  cycles,  about  the  supportability  needs  of  software  systems,  and  about  the  complex  data  rights 
provisions.  Although  our  investigation  taught  us  that  DoD  has  many  dedicated  and  intelligent 
procurement  officers,  it  also  taught  us  that,  by  and  large,  DoD’s  procurement  personnel  felt  that 
they  would  greatly  benefit  by  more  training  about  software  and  about  data  rights.  Many  DoD 
lawyers  who  have  been  working  in  the  patent  and  technical  data  rights  areas  could  also  benefit 
from  broadening  their  intellectual  property  expertise  to  include  copyright,  trade  secret,  and  chip 
protection. 

3.1  Procurement  Personnel  Need  Training 

SLP  investigators  interviewed  many  individuals  whose  job  included  acquiring  software  for  the 
government.  Those  with  whom  we  spoke  typically  exhibited  a  dedication  and  loyalty  to  their 
position;  they  seemed  to  sincerely  want  to  do  a  good  job.  Our  conclusion  is  that  DoD  already 
possesses  the  most  important  resource  needed  for  a  good  procurement  process  —  good  people. 
The  DoD  could,  however,  benefit  from  better  development  of  that  resource. 

3.1.1  Acquiring  Software,  Technical  Documentation  and  Data  Rights  is  a 
Complicated  Process 

The  process  of  procuring  a  system  is  extremely  complex  and,  at  times,  confusing.  The  contract¬ 
ing  people  must  have  a  grasp  of  and  be  able  to  deal  effectively  with  both  complicated  procure¬ 
ment  regulations  and  sophisticated  technology.  The  procurement  personnel  must  concern  them¬ 
selves  not  only  with  the  actual  physical  procurement  of  items  such  as  software,  but  also  must 
obtain  sufficient  technical  data  as  well  as  rights  in  the  data  and  the  software  in  order  to  allow 
maintenance  and  enhancement  of  the  system,  and  of  the  software  on  which  the  system  is  likely 
to  be  dependent.  Adequate  assessment  of  one’s  needs  with  regard  to  documentation  and  data 
rights  requires  at  least  a  basic  understanding  of  the  technology  to  be  acquired,  including  some 
knowledge  of  software  life  cycles. 

To  further  complicate  matters,  the  negotiations  regarding  the  software,  technical  data  and  rights 
thereto  will  often  occur  prior  to  or  simultaneously  with  the  actual  development  of  the  software,  and 
the  data  which  explains  the  software.  A  particular  piece  of  software  will  often  be  a  small,  but  vital 


component  to  be  embedded  within  a  sophisticated  system,  in  procuring  the  larger,  more  complex 
system,  the  procurement  personnel  must  deal  with  many  smaller  components,  any  one  of  which, 
while  it  may  seem  but  a  minor  element  in  the  overall  picture,  may  effectively  cripple  the  system  if 
the  technical  data  and  rights  that  have  been  acquired  prove  to  be  insufficient  to  implement,  main¬ 
tain  and/or  enhance  the  component  or  product. 
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Moreover,  this  procurement  process  often  takes  place  in  the  context  of  strong  pressure  on  con-  pi 

trading  personnel  to  "field"  the  system  as  fast  as  possible,  and  within  tight  budget  constraints. 

The  procurement  person  knows  that  his  or  her  performance  will  be  judged  on  the  basis  of  how 

quickly,  and  often  how  cheaply,  the  system  goes  from  inception  to  fielding,  not  on  how  well  the  v. 

system  is  supported  by  needed  documentation  and  data  rights.  As  one  contracting  individual  > 

informed  us,  "If  there's  a  delay  in  the  fielding  of  a  system  I  am  responsible  for  procuring  and  I  say 

it’s  because  I’m  negotiating  over  data  rights  or  technical  documentation  which  will  be  needed  for  \« 

maintenance  and  enhancement,  I’m  going  to  be  gone  in  a  hurry."  k£ 


3.1.2  Procurement  Personnel  Do  Not  Generally  Understand  Software  As  a 
Technology  or  Data  Rights 

Procurement  personnel  with  whom  we  spoke  often  indicated  to  us  that  they  felt  that  their  under¬ 
standing  of  software  as  a  technology  was  insufficient  to  allow  them  to  make  procurements  in  an 
optimal  way.  Moreover,  many  of  these  individuals  informed  us  that  their  lack  of  understanding  of 
the  technology  that  they  must  acquire  inhibits  their  ability  to  apply  the  software/data  rights 
procurement  regulations,  in  talking  with  these  individuals,  we  noted  that  they  sometimes  had 
difficulty  responding  to  questions  which  required  some  understanding  of  software  technology. 

Further,  virtually  all  of  the  contracting  people  we  talked  with  informed  us  that  they  do  not  have 
sufficient  knowledge  of  software  and  data  rights  to  enable  them  to  value  one  package  of  rights  as 
opposed  to  another.  That  is.  procurement  personnel  seem  not  to  understand  how  the  range  of 
potential  limitations  on  software  or  data  rights  may  affect  the  value  of  the  product  being  acquired. 
A  lack  of  valuation  ability  may  place  the  government  at  a  disadvantage  in  any  negotiation  involv¬ 
ing  limited  or  restricted  rights  packages.  It  is  difficult  to  effectively  negotiate  a  price  for  a  par¬ 
ticular  package  of  rights  if  one  cannot  gauge  the  value  of  that  package  as  opposed  to  another.  It 
seems  like  trying  to  buy  a  plane  when  one  does  not  know  what  a  plane  actually  does.  Without 
such  knowledge,  it  is  impossible  to  determine  the  value  of  the  product. 
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Similarly,  because  the  procurement  people  seem  not  to  fully  understand  the  technology  which  , 

they  are  purchasing,  they  may  not  fully  understand  the  application  of  the  procurement  regulations 

regarding  software  and  data  rights  to  the  acquisition  of  that  technology.  They  also  may  not 

realize  the  extend  of  discretion  afforded  them  under  those  regulations.  They  may  not  realize  that 

the  regulations  allow  them  to  structure  licensing  agreements  which  could,  in  effect,  serve  as 

middle  ground  alternatives  to  the  traditional  extreme  categories  of  unlimited  and  limited  or 

restricted  rights.  Again,  it  is  difficult  to  negotiate  effectively  when  one  does  not  understand  the  ^ 

range  of  freedom  one  is  permitted  to  exercise  in  those  negotiations.  ■ 
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If  contracting  personnel  lack  an  understanding  about  the  technology  they  are  purchasing,  they 

may  ask  for  much  more  in  the  way  of  technical  documentation,  data  rights  and  software  tools 

than  is  actually  needed  to  maintain  and/or  enhance  the  system.  The  same  is  true  if  they  do  not  j 

understand  the  life  cycle  of  the  software  they  are  acquiring,  or  what  information,  rights,  and  tools  j 

will  be  needed  in  order  to  maintain  and  enhance  the  system  property  throughout  its  life  cycle.  As  i 

a  result,  RFPs  are  said  to  be  vaguely  worded  about  maintenance,  and  contracting  people  may  i 

ask  for  more  than  would  be  necessary  to  support  the  system.  j 

I 

Industry  people  with  whom  we  have  spoken  have  indicated  to  us  that  if  DoD  contracting  person¬ 
nel  were  better  able  to  articulate  why  they  need  certain  documentation,  rights  or  tools  in  order  to 
support  a  system,  they  (industry)  would  be  more  willing  to  provide  that  which  has  been  requested. 

As  stated  in  the  'Report  of  the  Rights  in  Data  Technical  Working  Group  (RTDWG)  Volume  II:  j 

Supporting  Data  [13]  (a  report  prepared  under  the  auspices  of  the  Institute  for  Defense  Analysis 
for  the  Office  of  the  Under  Secretary  of  Defense  for  Research  and  Engineering,  and  released 
January  23, 1984),  the  government  needs  to 

. .  .  identify  what  this  equipment  «  going  to  do,  what  the  system  is  going  to  be,  and  what  its  life 
cycle  is  going  to  be  and  that  will  give  the  contractor  a  warmer  feeling  that  the  Government  has 
really  done  its  homework  instead  of  just  going  out  on  a  fishing  trip  for  all  of  the  data  rights, 
because  they  really  don't  know  what  they  want.  Report  at  21 1  -21 2. 

As  long  as  DoD  contracting  personnel  are  unable  to  specify  their  needs  as  to  technical  documen¬ 
tation,  data  rights  and  software  tools,  it  seems  likely  that  industry  people  will  regard  DoD’s  expan¬ 
sive  but  vague  claims  of  need  as  an  indication  that  the  government  has  simply  not  done  its 
'homework'  and  does  not  really  know  what  it  wants,  and  will  regard  such  claims  with  suspicion. 

A  report  prepared  by  the  OSD  Technical  Data  Rights  Study  Group  [1 1]  released  June  22,  1984, 
specifically  noted  the  need  for  additional  training  of  DoD  procurement  personnel  in  the  area  of 
technical  data  rights.  This  report,  prepared  by  a  study  group  panel  which  included  represen¬ 
tatives  of  the  Air  Force,  Army  and  Navy,  noted  that  "[cjurrerrtfy,  training  is  minimal  and  there  is  no 
requirement  to  attend  mandatory  training  in  the  data  rights  area.  Consequently,  personnel  are 
not  generally  conversant  with  policies,  procedures  and  clauses  regarding  application  of  rights  in 
technical  data  *  See  'Who  Should  Own  Data  Rights:  Government  or  Industry?  Seeking  a 
Balance"  at  42.  The  OSD  Study  Group  went  on  to  recommend  that  OSD  "coordinate  the 
development  of  a  comprehensive  training  program  in  the  area  of  technical  data  rights"  for  DoD 
contracting  personnel.  Another  OSD  report,  entitled  "DoD  Acquisition  Improvement  -  The  Chal¬ 
lenges  Ahead:  Perspectives  of  the  Assistant  Secretary  of  Defense  for  Acquisition  and  Logistics" 

(WadeReport,  released  November  5, 1985)  noted  this  same  concern  and  suggested  even  more 
far-reaching  changes  with  respect  to  the  DoD  acquisition  and  logistics  work  force  ( [4]  at  6-16). 
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3.1 .3  Need  for  e  Feedback  Mechanism 

Upon  the  fielding  of  a  system,  responsibility  for  that  system  passes  from  one  command  to 
another.  As  a  result,  the  people  who  must  deal  with  maintenance  and  enhancement  problems 
which  arise  due  to  inadequate  acquisition  of  documentation  and/or  data  rights  are  different  than 
the  people  who  originally  procured  the  system  and  supporting  material.  In  other  words,  the 
people  who  failed  to  get  adequate  documentation  and  rights  do  not  have  to  deal  with  the  sub¬ 
sequent  problems  which  their  lack  of  foresight  have  oocasioned.  Moreover,  it  appears  that  no 
mechanism  exists  whereby  the  procurement  personnel  are  made  aware  of  the  problems  oc¬ 
casioned  by  their  failure  to  acquire  certain  documentation  and/or  rights.  Without  such  feedback,  it 
seems  unlikely  that  the  procurement  people  will  have  the  incentive,  or  for  that  matter  the 
knowledge,  necessary  to  cause  them  to  confront  this  problem. 

3.1 .4  Industry  Can  Be  Expected  to  Exploit  DoD  Weaknesses 

It  can  also  be  expected  that  industry  will  exploit  the  weaknesses  in  DoD  procurement  practices.  If 
DoD  contracting  personnel  do  not  understand  the  product  they  are  purchasing,  and  make  broad 
vague  requests  for  rights  and  documentation  in  RFP's,  then  it  seems  likely  that  industry  will  sell 
the  government  those  rights  and  that  documentation  which  industry  is  willing  to  part  with,  whether 
the  government  really  needs  it  or  not.  In  a  sense,  that  is  simply  good  business.  If  the  govern¬ 
ment  tells  you  it  wants  to  buy  your  product  and  is  willing  to  meet  your  price,  why  not  sell  it  to 
them.  If  the  government  later  finds  it  really  didn't  need  the  product,  or  that  it  was  not  as  valuable 
to  the  government  as  it  originally  thought,  it  is  really  the  government’s  own  fault  for  not  having 
done  its  ’•homework." 

3.2  Preparation  of  Procurement  Personnel  for  Their  Role  in  System 
Acquisition 

3.2.1  Background  from  Which  Procurement  Personnel  Come  to  the  Job 

Our  research  indicates  that  procurement  personnel  come  from  a  variety  of  academic  and  profes¬ 
sional  backgrounds,  often  unrelated  to  the  type  of  work  they  will  be  doing  as  a  contracting  repre¬ 
sentative  for  the  government.  Very  few  have  any  background  in  technically  oriented  fields,  such 
as  engineering,  which  would  aid  them  in  understanding  the  technology  involved  in  the  systems 
they  are  charged  with  acquiring.  An  almost  universal  response  of  those  with  whom  we  spoke,  a 
group  which  included  procurement  personnel,  engineers,  and  attorneys,  was  that  some  under¬ 
standing  of  the  technology  involved  in  the  system  —  especially  with  regard  to  software,  technical 
documentation,  life  cycle  concerns,  and  data  rights  —  would  be  very  helpful  to  the  procurement 
personnel  in  the  performance  of  their  mission.  It  was  as  widely  acknowledged  that  such 
knowledge  is,  at  this  time,  lacking. 
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3.2.2  Initial  Training  Received  by  Procurement  Personnel  Does  Not  Prepare  Them 
to  Deal  with  Software/Data  Rights  Acquisitions 

Currently,  it  appears  that  procurement  personnel  receive  no  initial  training  as  to  the  technology 
involved  in  software,  technical  documentation,  and  data  rights  which  they  are  charged  with  ac¬ 
quiring;  nor  do  they  receive  any  training  which  would  enable  them  to  understand  life  cycle  con¬ 
cerns  which  are  so  important  in  this  area.  Consequently,  the  software/data  rights  area  is  an  area 
of  weakness  with  regard  to  DoD  procurement  practices. 

The  contracting  personnel  with  whom  we  have  spoken  identified  this  deficiency  as  a  major  flaw  in 
their  preparation  for  the  role  in  which  they  function.  Indeed,  the  people  we  spoke  with  indicated 
that,  with  the  exception  of  a  few  initial  courses  covering  areas  such  as  basic  contract  law  and 
procurement  management,  almost  all  of  the  preparation  they  have  received  for  the  work  they  do 
has  been  in  the  form  of  on  the  job  training. 

3.2.3  Supervision  and  on  the  Job  Training  of  Contracting  Personnel  Has  Been 
Weak  in  Recent  Years  Due  to  a  Shortage  of  Experienced  Personnel  in  This 
Area 

Procurement  personnel  normally  work  their  way  up  through  the  ranks.  (Division  Chiefs  were  at 
one  time  Contract  Officers,  Contract  Officers  began  as  Contract  Negotiators,  and  so  on.)  Super¬ 
visory  personnel  thus  understand  the  job  of  those  they  supervise,  and  have  the  knowledge 
necessary  to  assist  them.  Thus,  on  the  job  training  plays  an  important  role  in  the  development  of 
the  procurement  officer's  skills.  There  has,  however,  reportedly  been  a  decline  in  the  number  of 
experienced  procurement  personnel  on  the  job  for  the  DoD.  In  one  command,  we  were  told, 
fifty-five  per  cent  of  the  procurement  people  were  inexperienced.  The  more  inexperienced  the 
staff,  the  less  efficient  will  be  the  on-the-job  training. 

3.3  Ongoing  Training  of  Procurement  Personnel 
3.3.1  Current  Status  of  Ongoing  Training 

Our  research  found  that  procurement  personnel  typically  do  receive  some  form  of  ongoing  train¬ 
ing,  a  kind  of  continuing  education  or  in-service  training.  This  ongoing  training,  generally 
provided  on  a  monthly  basis,  has,  however,  tended  to  focus  on  what  one  contracting  person 
referred  to  as  current  "hot  issues."  For  example,  the  emphasis  of  sessions  during  our  interview 
period  had  been  on  the  Competition  in  Contracting  Act,  particularly  what  it  means  to  procurement 
personnel.  Software  and  data  rights  issues,  we  were  told,  have  tended  to  be  overlooked  in  such 
training. 


3.3.2  Thoughts  of  Procurement  Personnel  Regarding  Ongoing  Training  Needs 

Procurement  personnel  with  whom  we  spoke  generally  felt  that  some  form  of  training  in  the  areas 
of  software  and  data  rights  would  be  very  useful  for  them.  Most  expressed  the  view  that  some 
background  in  these  areas  would  give  them  a  greater  feeling  of  confidence  in  their  ability  to 
effectively  negotiate  for  and  purchase  such  products.  Further,  the  people  with  whom  we  have 
spoken  have  often  expressed  the  view  that  such  training  should  include  some  coverage  of  the 
regulations  (FAR  and  DoD  FAR  SUPP)  which  cover  software  and  data  rights  procurement  issues. 
Many  of  the  individuals  who  must  work  with  and  within  these  regulations  find  them  to  be  confus¬ 
ing,  and  therefore  feel  that  some  explanation  of  their  function  and  purpose  would  be  helpful. 

While  those  we  have  spoken  with  have  expressed  differing  views  on  the  structure  a  course  on 
software  and  data  rights  issues  should  take,  most  have  felt  that  a  two  day  seminar  format  would 
be  most  appropriate.  A  common  complaint  about  training  attempts  in  other  areas  was  that  too 
often  there  has  been  too  much  material  crammed  into  a  few  short  hours  of  time,  with  the  result 
that  the  participants  took  little  useful  information  away  from  the  course.  Many  felt  a  two  or  three 
day  format  was  the  optimal  blend  —  allowing  enough  time  for  some  in  depth  coverage  of  a 
subject,  but  not  so  long  that  people  lost  interest.  Most  of  the  people  with  whom  we  spoke  were 
concerned  that  if  an  effort  was  undertaken  to  provide  training  as  to  software  and  data  rights,  the 
course  should  be  relatively  substantive  in  nature,  not,  as  one  contracting  person  we  spoke  with 
put  it,  "a  summary  of  the  fact  that  we  have  problems." 

Other  suggestions  included  that  the  course  be  developed  and  implemented  by  an  outside  con¬ 
sultant  so  as  to  provide  a  more  objective  view  of  some  of  the  controversial  issues  which  arise 
when  discussing  software  and  data  rights  issues.  It  was  also  suggested  that  such  a  course  could 
then  be  presented  at  various  bases. 

3.4  The  Need  for  More  Specialization  and  Broader  Expertise  by  DoD 
Lawyers 

DoD  has  some  very  fine  and  experienced  patent  and  technical  data  rights  lawyers.  These  are  the 
people  who  tend  to  advise  DoD  about  software  intellectual  property  matters.  Unfortunately, 
sometimes  these  lawyers  do  not  have  as  much  expertise  in  the  areas  of  copyright,  trade  secret, 
trademark,  and  chip  protection  laws,  all  of  which  are  now  necessary  to  provide  comprehensive 
legal  guidance  in  software  acquisition  matters.  Copyright  law  differs  from  patent  law  in  a  number 
of  important  respects.  (The  government,  for  example,  can  own  patents  but  not  copyrights 
directly.)  DoD  should  encourage  more  specialization  on  software  intellectual  property  matters  as 
well  as  a  broadened  approach  to  understanding  software  legal  protection  by  its  lawyers. 

3.5  Recommendations 

1 .  Develop  and  implement  a  training  program  regarding  software  and  data  rights  acquisition  for 
procurement  personnel,  as  previously  recommended  by  the  OSD  Study  Group.  Such  training 
might  be  done  in  a  two  to  three  day  seminar  format  which  could  be  presented  periodically  at 


various  locations  where  procurement  personnel  work.  Some  version  of  the  training  might  also  be 
included  in  the  initial  training  received  by  new  procurement  personnel. 

The  training  should  include,  as  a  minimum,  some  coverage  of. 

a.  How  to  deal  with  software/data  rights  acquisitions  in  an  RFP,  including  some  focus  on 
adequate  specification  of  what  is  being  requested. 

b.  What  software  is,  and  how  technical  documentation,  data  rights  and  software  tools  apply  to  it. 

c.  Why  life  cycle  concerns  are  important  to  software  acquisition. 

d.  Why  maintenance  and  enhancement  concerns  are  important  to  the  system/software  being 
acquired. 

e.  How  technical  documentation,  data  rights,  software  tools,  and  life  cycle  concerns  affect  the 
ability  to  maintain  and  enhance  system  software. 

f.  How  to  understand  and  apply  the  procurement  regulations  relating  to  software/data  rights 
acquisitions. 

g.  What  flexibility  and  discretion  is  afforded  contracting  personnel  under  the  relevant  regula¬ 
tions. 

2.  Provide  for  greater  standardization  in  RFP’s.  Such  standardization  should  include  a  focus  on: 

a.  A  clearer  specification  of  what  is  being  requested. 

b.  Incorporating  some  mechanism  whereby  maintenance/enhancement  concerns  will  be  recog¬ 
nized  and  dealt  with  at  the  RFP  stage  of  a  procurement. 

3.  Develop  a  feedback  mechanism  whereby  procurement  personnel  will  be  made  aware  of 
maintenance/enhancement  problems  which  arise  as  a  result  of  inadequate  system  support. 
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4.  Reusability  and  Other  Derivative  Works  Problems  Involving 
Software 


There  has  been  considerable  interest  in  recent  years  within  the  Department  of  Defense  about 
promoting  "reusability"  of  software.  For  a  variety  of  reasons,  discussed  briefly  below,  software 
reuse  is  an  attractive  idea.  However,  DoD  personnel  seem  troubled  by  a  range  of  problems  with 
attempting  to  implement  reusability  projects.  Among  the  more  serious  of  these  problems  is  how 
DoD  might  make  appropriate  licensing  arrangements  with  private  firms  so  as  to  promote  reuse  of 
software.  It  is  not  yet  clear  that  software  reuse  will  be  able  to  live  up  to  the  promise  that  some  of 
its  promoters  have  held  out  for  it. 

It  is,  of  course,  important  to  understand  that  software  ‘reuse’  is  a  term  that  refers  to  a  wide 
variety  of  things,  including  large  software  programs  composed  largely  of  modules  of  standard 
code  that  can  be  combined  to  produce  specific  application  programs,  programs  that  are  built 
upon  and  incorporate  all  or  part  of  pre-existing  programs,  programs  that  were  developed  in  con¬ 
junction  with  one  government  project  that  are  furnished  on  a  "GFI"  (government  furnished 
information)  basis  to  subsequent  contractors  for  use  in  subsequent  projects,  and  even  reuse  of 
software  designs  or  algorithms  when  writing  new  application  software.  There  is  a  lively  con¬ 
troversy  within  DoD  over  which  model  of  reuse  is  the  "best"  or  "most  appropriate"  model  from  a 
technical  standpoint.  We  do  not  have  the  technical  expertise  to  assess  the  merits  of  the  claims 
made  for  or  against  the  various  models  of  reuse.  Although  different  models  of  reuse  may  present 
different  technological  challenges,  each  has  a  common  legal  denominator.  Each  may  be  an 
instance  of  a  "derivative  works"  right  problem  under  the  copyright  law. 

Copyright  law  gives  the  owner  of  a  copyrighted  piece  of  software  the  exclusive  right  to  oontrol  the 
preparation  of  "derivative  works’  from  the  original  work.  Copyright  law  defines  "derivative  work" 
in  a  broad  fashion;  it  is  a  work  based  upon  another  work.  [59]  sec.  101 .  Although  there  is  as  yet 
little  case  law  to  flesh  out  the  meaning  of  the  derivative  works  right  in  the  software  context,  it  is 
conceivable  -  perhaps  even  likely  -  that  all  models  of  software  reuse  discussed  above  may 
create  derivative  works  problems  unless  the  reuser  is  the  same  person  as  the  owner  of  the 
original  copyrighted  software. 

Unfortunately,  it  is  not  just  software  reuse  that  seems  to  raise  derivative  works  problems  for  the 
government.  Modification  and  enhancement  of  software  also  are  instances  of  creating  derivative 
works.  Translating  code  from  one  computer  language  to  another,  revising  code  so  that  it  can  be 
executed  on  different  hardware  or  so  that  it  can  generate  code  to  be  executed  on  different  kinds 
of  hardware,  and  perhaps  even  all  forms  of  computer-generated  works  may  be  within  the  mean¬ 
ing  of  the  "derivative  works"  right  under  the  copyright  law. 

DoD's  acquisition  regulations  are  not  currently  structured  so  as  to  facilitate  licensing  arrange¬ 
ments  that  will  promote  reuse  of  software  or  harmoniously  deal  with  other  forms  of  the  derivative 
works  problems.  DoD  lawyers  seem  inexperienced  with  software  technology  and  with  the  in- 
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tricacies  of  the  copyright  law  as  it  affects  the  many  different  types  of  derivative  worte  of  software 
with  which  DoD  must  deal.  To  understand  how  the  derivative  works  right  may  limit  the 
government’s  rights  as  to  software,  this  Chapter  will  first  discuss  reuse  and  then  the  other  forms 
of  derivative  works  with  which  DoD  must  be  concerned. 


4.1  Reusability  of  Software  -  The  Pros  and  the  Cons 

Reuse  of  software  is  an  attractive  idea.  For  one  thing,  if  software  was  reused,  there  would  likely 
be  more  standardization  of  software  and  software  components,  which  would  seem  a  promising 
step  toward  solving  some  of  the  current  problems  with  support  ability  and  maintainability  of 
software  raised  in  Chapter  2.  Greater  consistency  and  reliability  in  software  would  also  seem  to 
be  potential  benefits  of  reusability.  Reusability  also  holds  out  some  promise  of  saving  con¬ 
siderable  amounts  of  money,  or  at  least  of  allowing  DoD  to  get  more  or  better  software  for  the 
same  money.  It  was  widely  believed  by  DoD  personnel  to  whom  we  spoke  that  DoD  was  paying 
time  and  time  again  for  development  of  the  same  software  or  software  components.  It  was  widely 
believed  that  software  costs  would  be  reduced  if  software,  or  at  least  certain  common  functions  in 
software,  were  able  to  be  routinely  reused.  Also,  reuse  would  seem  to  promise  reduced  software 
development  time.  If  one  can  use  this  standard  input-output  routine  and  that  filter  and  this  stan¬ 
dard  whatever,  and  put  one’s  programming  effort  into  providing  the  "glue”  with  which  to  put  the 
standard  components  together,  or  into  making  certain  necessary  enhancements  to  some  com¬ 
ponents,  surely  that  should  reduce  the  time  it  takes  to  develop  software.  Perhaps  this  would  also 
free  up  software  engineers  to  tackle  more  difficult  software  development  problems. 


Given  these  (and  other)  prospective  advantages  of  reusability  of  software,  it  is  no  wonder  that 
DoD  personnel  are  seriously  interested  in  promoting  reusability  and  no  wonder  that  DoD  has 
invested  considerable  sums  in  reusability  projects.  Yet,  some  initial  experiences  in  reusability 
have  revealed  a  considerable  number  of  problems  with  the  concept,  some  of  which  pertain  to  the 
feasibility  of  making  appropriate  licensing  arrangements  if  software  is  reused. 


4.1 .1  The  Debate  over  "GFI"  Software 

Among  the  many  current  "reuse"  issues  being  debated  within  DoD  is  whether  it  is  appropriate  to 
provide  software  developed  by  one  contractor  to  a  second  contractor  on  a  "government  furnished 
information"  (GFI)  basis  (which  would  require  the  second  firm  to  use  the  first  firm’s  software).  It  is 
our  understanding  that  the  Navy  and  the  Air  Force  have  different  views  on  this  issue.  The  Navy 
is  more  favorably  disposed  to  this  practice  than  is  the  Air  Force.  Air  Force  people  to  whom  we 
spoke  regarded  the  problems  likely  to  arise  if  this  kind  of  software  reuse  was  attempted  to  be  so 
many  and  so  serious  as  to  outweigh  the  potential  benefits.  Without  attempting  to  take  a  stand  on 
the  merits  of  either  position  or  to  promote  this  model  of  reuse  over  others,  it  seems  worthwhile  to 
detail  the  controversy  to  illustrate  the  more  general  problem  of  how  to  make  appropriate  arrange¬ 
ments  for  reuse. 

Here  is  the  Air  Force’s  argument:  suppose  one  decides  to  require  reuse  of  radar  software 
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developed  by  company  A  in  a  contract  for  another  radar  system  to  be  developed  by  company 
B.  Doing  so  will  constrain  choices  about  other  elements  of  the  radar  system,  such  as  what  com¬ 
puter  and  operating  system  company  B  can  use.  These  constraints,  in  turn,  may  limit  other 
choices.  Company  B  may  well  think  that  these  constraints  will  inhibit  its  development  of  a  supe¬ 
rior  system.  Moreover,  unless  the  two  radar  systems  are  intended  to  serve  precisely  the  same 
function  in  precisely  the  same  way,  reusability  requirements  can  lead  to  trouble.  It  is  common 
knowledge  that  many  adjustments  in  software  (to  add  a  new  capability,  to  modify  a  function,  even 
to  fix  a  bug)  can  create  unforeseen  problems  with  the  unmodified  portions  of  the  software,  some 
of  which  may  show  up  immediately,  some  of  which  may  show  up  down  the  line.  Documentation 
about  the  software  obtained  from  A  and  given  to  B  may  either  be  inadequate  or  incomprehensible 
to  B,  which  may  further  increase  the  risk  of  unintended  ill  effects  when  making  the  necessary 
modifications  for  the  second  radar  system.  Reuse  may  also  mean  using  "old"  technology  instead 
of  new  and  better  technology.  Perhaps  even  more  significant  than  these  problems  with 
reusability  is  the  practical  problem  of  giving  company  B  a  handy  scapegoat  whenever  there  are 
problems  with  the  second  radar  system:  it  will  always  be  said  to  be  the  fault  of  the  GFIed 
software. 

Yet  the  Navy  seems  willing  to  accept  these  risks  and  has  taken  to  evaluating  bids  for  certain  new 
systems  based  on  the  percentage  of  software  reuse  the  bidders  are  willing  to  commit  to  making, 
and  are  requiring  use  of  certain  software  on  a  GFI  basis  in  subsequent  projects. 

Creating  structural  incentives  for  the  contractors  to  reuse  either  their  own  or  other  software  would 
seem  to  be  a  promising  short  term  strategy  for  the  Defense  Department.  It  might  also  be  benefi¬ 
cial  to  do  follow  up  studies  of  Navy  reuse  projects.  Perhaps  the  Navy  approach  will  be  proven 
more  viable  than  Air  Force  personnel  seem  currently  to  believe. 


4.1 .2  Ownership  Issues  and  the  Derivative  Works  Problem  with  Reuse 

There  seemed  to  be  considerable  consensus  among  DoD  personnel  to  whom  we  spoke  that 
unless  the  government  owned  or  had  unlimited  rights  in  software  to  be  reused,  reuse  would  be 
difficult  to  impossible  to  achieve.  Although  company  A  in  the  radar  example  above  might  be 
willing  to  license  company  B's  use  of  its  proprietary  software,  the  government  can  not  count  on 
company  A’s  cooperation,  because  company  A  may  prefer  to  have  the  follow-on  contract.  Even  if 
company  A  was  willing  to  license  reuse,  it  could  be  expected  to  charge  B  a  rather  hefty  sum  for 
the  privilege  of  reuse,  which  might  mean  that  the  ultimate  cost  savings  to  the  government  from 
reuse  would  be  minimal  to  nonexistent.  And  even  if  company  A  gets  the  follow-on  oontract  and 
reuses  its  own  software,  that  may  only  reduce  the  time  required  for  development,  not  necessarily 
the  cost  (at  least  not  by  much  since  company  A  might  be  a  low  bidder  only  by  comparison  with 
the  bids  of  others  who  would  have  to  develop  the  software  from  scratch).  As  with  competitive 
maintenance,  reusability  of  software  is  made  more  difficult  when  proprietary  software  is  involved. 

Even  if  the  government  has  paid  for  the  development  of  the  software  intended  for  reuse  and 
expects  to  get  unlimited  rights  in  the  software,  there  may  be  a  problem  with  actually  getting 
unlimited  rights:  if  the  development  firm  decides  to  take  a  copyright  in  the  software,  the  govern- 
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merit  may  be  reduced  to  having  a  governmental  purpose  license  in  it  (See  Chapter  1).  The 
government's  ability  to  authorize  other  firms  to  reuse  this  software,  for  purposes  other  than  the 
governmental  project  (i.e.,  for  any  potential  commercial  spinoffs)  may  be  seriously  jeopardized  by 
the  restrictions  of  the  governmental  purpose  license  (See  Chapter  7).  The  government  will  also 
have  the  same  problems  getting  adequate  documentation  from  company  A  to  give  to  company  B 
for  software  reuse  purposes  as  it  does  in  getting  the  documentation  for 
maintenance/enhancement  purposes  (See  Chapter  2). 

In  addition  to  the  idea  of  reusing  specific  software  from  one  project  to  another  (as  in  the  radar 
example),  there  is  growing  interest  in  broader  scale  reusability  projects,  such  as  creating 
programs  consisting  of  thousands  of  modules  of  code,  different  combinations  of  which  can  be 
formed  to  produce  different  software.  Some  programs  of  this  sort  have  already  been  developed. 
Some  are  proprietary.  Some  have  been  prepared  by  government  engineers  and  programmers. 

It  is  clear  that  if  the  baseline  program  is  proprietary,  then  modules  of  it  will  also  be  proprietary. 
Use  of  such  a  proprietary  base  program  to  create  application  software  consisting  of  some  of  the 
base  program's  modules  would  seem  to  create  a  proprietary  derivative  work.  Certainly  if  the 
base  program  is  copyrighted,  it  would  seem  that  the  user  would  need  the  copyright  owner’s 
permission  to  create  such  derivative  works.  This  permission  might  be  limited  or  withheld.  For 
example,  the  owner  of  the  base  program  might  limit  use  to  creation  of  certain  kinds  of  application 
software,  or  may  make  the  right  to  this  sort  of  reuse  contingent  upon  payment  of  additional 
royalties  (besides  whatever  fee  one  paid  to  obtain  access  to  the  base  program).  If  one  wished  to 
use  two  or  more  proprietary  base  programs  owned  by  different  companies  to  create  new  software 
with  modules  from  each,  one  might  need  each  company’s  explicit  permission.  Some  companies 
might  object  to  incorporation  of  modules  from  another  system.  It  is  difficult  to  imagine  how  to  deal 
with  all  the  many  conflicting  proprietary  claims  and  the  many  claims  for  additional  royalties  every 
time  each  standard  module  is  used.  (Think  of  how  many  pieces  of  software  have  the  same  basic 
I/O  routine).  This  set  of  complexities  has  led  many  in  the  government  to  doubt  the  advisability  of 
making  use  of  proprietary  reuse  programs  of  this  sort. 

4.1.3  incentive  Problems  with  Broad  Rights  to  Reuse  in  the  Government 

These  concerns  about  reusability  of  proprietary  software  has  led  many  to  insist  that  the  govern¬ 
ment  must  own  the  software  or  have  unlimited  rights  to  make  software  reuse  feasible  at  all. 

Some  in  DoD,  though,  worry  about  the  quality  of  large  scale  reuse  programs  developed  either 
internally  at  DoD  or  by  private  companies  for  the  government.  Although  DoD  does,  in  fact, 
develop  a  lot  of  software  in-house,  that  is  not  its  main  mission  or  the  thing  that  it  does  best.  The 
quality  of  software  produced  by  the  government  may  not  be  as  high  as  that  produced  by  a 
top-notch  software  development  firm.  And  private  firms  may  lack  incentives  to  develop  outstand¬ 
ing  reusability  programs  for  the  government,  that  is,  programs  in  which  the  government  would 
have  unlimited  rights  and  for  which  the  government  would  have  to  pay  no  further  royalty,  no 
matter  how  much  reuse  was  made  of  its  modules.  (This,  of  course,  is  precisely  what  many 
government  people  want:  to  buy  one  excellent  program  and  not  have  to  pay  again  each  time  a 
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new  program  is  created  through  its  use.)  A  firm  that  developed  a  "perfect"  program  of  this  sort 
would,  in  essence,  put  itself  out  of  business  after  its  first  sale  to  the  government,  for  if  the  govern¬ 
ment  had  unlimited  rights,  the  government  could  give  the  reusable  code  away  to  anyone  and 
everyone  if  it  so  chose.  Even  a  follow-on  contract  for  maintenance  might  be  of  limited  interest  to 
the  developer  of  reusable  modules. 

If,  however,  the  firm  could  be  sure  it  could  have  a  substantial  commercial  market  for  the  reuse 
program  without  fear  of  government  "giveaways,"  or  if  the  firm  could  collect  a  royalty  upon  reuse 
of  its  components,  then  theoretically  it  would  have  a  strong  incentive  to  create  an  excellent  set  of 
modules  so  that  its  modules  would  be  used  instead  of  those  of  another  firm.  (Of  course,  it  is 
important  to  remember  that  in  the  real  world  there  is  a  big  difference  between  creating  incentives 
for  excellence  and  the  actual  creation  of  an  excellent  product.) 

4.1.4  Problems  Associated  with  Configuration  Management  or  Libraries  for 
Reusable  Software 

Several  DoD  personnel  with  whom  we  spoke  about  reusability  of  software  expressed  doubts 
about  the  feasibility  of  efficient  and  cost-effective  software  reusability,  given  the  substantial  costs 
associated  with  managing  the  large  volume  of  data  needed  to  keep  track  of  all  the  software 
components  the  government  might  want  to  reuse.  This  challenge  is  by  no  means  peculiar  to  the 
DoD.  Reuse  of  software  requires  an  elaborate  library  or  cataloguing  system,  whereby  both  the 
government  and  subsequent  software  developers  can  be  made  aware  of  and  have  access  to 
software  which  can  be  reused.  While  the  development  of  such  an  accessing  system  does 
present  some  challenge,  it  may  not  be  insurmountable.  [1] 

4.2  Other  Derivative  Work  Problems 

Software  is  now  considered  to  be  copyrightable  subject  matter.  Although  not  all  software  is 
copyrighted,  much  of  it  is.  Many  firms  that  claim  copyright  protection  for  their  software  also  claim 
trade  secret  protection  for  the  same  software.  Copyright  owners  have  the  exclusive  right  to 
prepare,  or  authorize  preparation  of,  derivative  works.  [59]  sec.  106  (2).  The  derivative  works  right 
can  give  rise  to  a  number  of  different  types  of  problems  in  addition  to  those  already  discussed  in 
Section  4.1 ,  each  of  which  is  discussed  below. 

4.2.1  Maintenance  and  Enhancement  of  Software 

Because  another  chapter  has  been  devoted  to  this  topic,  this  section  will  do  no  more  than 
reiterate  that  when  the  government  maintains  or  enhances  software,  in  each  instance  it  may  be 
creating  a  derivative  work  which,  unless  authorized,  might  infringe  any  copyright  held  in  the 
software  by  a  private  firm  (except  for  the  fixing  of  a  "bug"  that  had  rendered  the  software  in¬ 
operable,  which  would  be  privileged  under  section  117  of  the  copyright  law.)  Because  of  the 
broad  definition  accorded  the  concept  of  a  derivative  work,  it  is  conceivable  that  even  main¬ 
tenance  efforts  might  fall  with  its  scope. 
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Fortunately,  the  government,  through  the  standard  data  rights  clause,  always  has  modification 
rights  in  any  software  acquired  under  the  DoD  FAR  SUPP.  But  as  pointed  out  in  Chapter  2 
above,  the  government  does  not,  as  a  matter  of  course,  have  the  right  to  sublicense  its  modifica¬ 
tion  rights  to  others.  To  sublicense  the  modification  right  in  copyrighted  trade  secret  software 
without  the  software  owner's  permission  creates  the  risk  of  injunctive  relief  being  entered  against 
the  government.  (See  Chapter  9.) 

Who  owns  what  rights  in  modified  or  enhanced  software  can  be  an  extremely  complicated  ques¬ 
tion  because  of  a  copyright  rule  that  limits  or  negates  copyright  protection  for  any  derivative  work 
made  without  the  copyright  owner's  full  authorization.  [59]  sec.  103  (a).  Because  the  present 
procurement  regulations  seem  to  give  the  government  authority  to  prepare  derivative  works  of 
copyrighted  software  developed  at  public  expense  only  for  government  purposes,  the  rights  of  the 
firm  that  made  the  modifications  to  make  use  of  the  modifications,  even  on  its  own  copy  of  the 
same  software,  may  be  limited  by  the  copyright  rule.  (See  Chapters  1  and  7.) 

4.2.2  Duty  Not  to  Create  Similar  Derivative  Software  of  Privately  Funded  Software 

The  government  clearly  has  the  right  to  modify  the  software  in  which  it  has  obtained  rights,  to 
maintain  it  and  to  add  a  new  capability  needed  to  make  the  software  better  able  to  do  the  thing  it 
was  acquired  to  do.  It  is,  however,  a  different  question  whether  the  government  has  the  right  to 
create  another  piece  of  derivative  software,  such  as  the  translation  of  a  program  originally  written 
in  JOVIAL  to  one  written  in  Ada,  without  the  permission  of  the  owner  of  a  copyright  in  the  original 
software.  Indeed,  the  DoD  FAR  SUPP  contains  a  policy  statement  indicating  that  proprietary 
software  documentation  will  not  be  used  to  create  other  similar  software.  [61]  sec.  27.404-1  (e). 

4.2.3  Authority  to  Create  Derivative  Software  if  Publicly  Funded 

If  the  government  has  funded  the  development  of  software,  it  usually  expects  to  have  unlimited 
rights  in  the  software.  If  the  government  has  unlimited  rights  in  software,  an  argument  can  be 
made  that  it  has  the  right  to  create  or  authorize  creation  of  derivative  software.  However,  strictly 
speaking,  the  definition  of  unlimited  rights  refers  to  "use,"  "copy,"  and  "disclose”  as  the  rights  the 
government  has,  which  could  give  rise  to  an  argument  that  creating  a  derivative  work  is  not  within 
the  scope  of  unlimited  rights.  The  copyright  statute  could  be  cited  to  support  this  strict  construc¬ 
tion  because  of  its  separation  of  "copying"  and  "creating  of  derivative  works"  [59]  sec.  106.  Some 
clarification  of  the  government’s  right  to  create  derivative  works  in  the  definition  of  "unlimited 
rights"  might  be  wise. 

Also,  as  Chapter  1  has  indicated,  the  government’s  payment  of  the  development  costs  of 
software  does  not  necessarily  mean  that  it  has  truly  "unlimited"  rights  in  the  software.  The 
developer  of  such  software  has  the  right  under  the  present  regulations  to  take  a  copyright  in  it. 
with  a  license  back  to  the  government  to  use  it  for  governmental  purposes.  This  would  seem  to 
mean  that  the  government’s  authority  to  authorize  others  to  prepare  derivative  works  is  thereby 
limited.  As  Chapter  7  indicates,  this  may  mean  that  the  original  contractor  would  probably  be 
able  to  prevent  any  contractor  who  prepared  a  derivative  work  for  the  government  from  marketing 
the  derivative  work  commercially. 
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4.2.4  Reuse  of  Software  Designs 

The  government  may  sometimes  want  to  reuse  the  design  of  a  piece  of  copyrighted  software  in 
another  software  project.  The  question  is  whether  the  government  needs  to  worry  about 
copyright  interests  in  such  a  case.  Recent  copyright  precedents  have  suggested  that  reuse  of 
software  designs  may  infringe  the  copyright  (e.g.,  Whelan  Associates,  Inc.  v.  Jaslow  Dental  Labs, 
Inc.  [50])  finding  infringement  of  dental  laboratory  software  copyright  based  on  structural 
similarities  between  programs).  There  are  some  copyright  scholars  who  would  argue  that  reuse 
of  software  designs  involves  reuse  of  ideas,  methods,  processes,  and  discoveries  of  the  software 
which  do  not  infringe  the  copyright  law  under  17  U.S.C.  sec.  102(b)  [59]  but  as  yet  the  issue  is 
unsettled.  It  again  creates  a  potential  for  liability  against  the  government  if  care  is  not  taken  in 
licensing  arrangements  with  respect  to  the  original  software. 

4.2.5  Government  Rights  in  Contractor-Prepared  Derivative  Programs 

A  problem  discussed  at  some  length  in  Chapter  7  is  what  rights  the  government  should  have  in 
subsequently  developed  derivative  software  made  from  software  prepared  for  and  funded  by  the 
government.  The  government  will  sometimes  want  to  claim  rights  in  these  derivatives,  even 
though  there  may  be  no  contractual  obligation  requiring  the  contractor  to  give  the  government  a 
copy.  Copyright  law  would  not  seem  to  give  the  government  rights  in  the  derivative  software 
unless  the  government  had  an  ownership  interest  in  the  original  copyright. 

4.2.6  Programs  Produced  Through  Use  of  Other  Programs 

As  noted  above,  there  would  seem  to  be  copyright  problems  if  modules  of  proprietary  software 
were  "reused*  by  combining  them  together  to  create  a  new  piece  of  application  software  because 
a  derivative  work  would  seem  to  have  been  created.  In  such  a  case,  portions  of  identical  code 
would  be  included  in  the  new  work.  A  copyright  owner  in  the  baseline  program  would,  therefore, 
seem  under  the  copyright  law  to  be  the  owner  of  intellectual  property  rights  in  the  new  application 
software.  Arguments  might  be  made  that  this  should  not  be  an  infringing  derivative  work  since  it 
is  the  very  purpose  of  the  base  program  to  produce  application  software,  however  the  question  is 
a  close  one,  and  if  it  matters  to  DoD  what  the  answer  is,  making  appropriate  contractual  arrange¬ 
ments  to  allocate  ownership  would  seem  wise. 

An  even  closer  and  potentially  more  troublesome  question  is  whether  the  owners  of  copyrights  in 
software  tools  (or  other  types  of  software  capable  of  being  used  to  create  new  software)  have  any 
claim  to  rights  in  programs  produced  through  use  of  their  proprietary  programs.  The  definition  of 
derivative  work  under  the  copyright  law  is  sufficiently  vague  that  it  is  conceivable  that  a  court 
might  find  software  generated  through  use  of  other  software  to  be  a  derivative  work.  In  such  an 
instance,  the  code  would  not  be  identical,  but  the  second  piece  of  code  would  be  "derived"  from 
the  first. 

It  is  conceivable  that  a  contractor  might  attempt,  pursuant  to  a  software  license,  to  claim  rights  in 
software  developed  by  the  government  through  use  of  the  contractor’s  software.  We  have  heard 


of  two  instances  of  such  claims  in  the  commercial  marketplace:  one  in  which  the  producer  of  a 
compiler  claimed  rights  to  royalties  in  compiled  code,  the  other  in  which  the  producer  of  an 
operating  system  claimed  rights  to  prevent  sales  of  programs  developed  through  use  of  the 
operating  system  to  entities  other  than  the  operating  system’s  owner.  It  may  be  this  idea  will 
catch  on  more  widely  over  time.  DoD  might  want  to  consider  putting  a  provision  in  the  procure¬ 
ment  regulations  to  the  effect  that  the  government  shall  own  rights  in  the  software  produced 
through  use  of  other  software,  just  to  be  on  the  safe  side. 


5.  Government  Ownership  of  Copyrights 


When  DoD  wants  to  take  a  direct  ownership  interest  in  a  work  prepared  for  it  by  a  private  contrac¬ 
tor,  the  DoD  FAR  SUPP  directs  that  the  'special  works'  clause  found  at  DoD  FAR  SUPP  ( [61] 
sec.  52.227-7020)  be  used  in  the  development  contract  ( [61]  sec.  27.405).  The  clause  in  effect 
claims  a  direct  copyright  for  the  government  under  the  copyright  "work  made  for  hire”  doctrine. 
We  understand  that  this  "special  works"  clause  has  been  used  in  a  number  of  DoD  software 
development  contracts.  Indeed,  it  appears  that  a  deviation  would  be  required  to  attempt  take  a 
copyright  interest  in  any  other  manner. 

There  are  two  problems  with  use  of  the  special  works  clause  for  this  purpose,  one,  that  software 
is  not  one  of  the  categories  of  specially  commissioned  works  that  qualifies  for  "work  made  for 
hire’  rules,  and  second,  that  the  copyright  law  specifically  prohibits  the  government  from  taking 
direct  ownership  rights  in  copyrighted  works  ( [59]  sec.  105).  The  legislative  history  of  this  section 
reflects  that  Congress  considered  the  issue  of  copyright  ownership  of  works  prepared  for  the 
government  by  contractors  and  decided  that  while  agencies  could  decide  that  contractors  could 
be  permitted  to  retain  copyrights,  the  government  could  not  get  direct  copyright  ownership  in 
works  prepared  for  it.  ( [6]  at  59.) 

Copyright  law  permits  the  government  to  own  copyrights  only  by  assignment,  bequest,  and  the 
like.  Taking  a  copyright  as  if  the  work  was  "made  for  hire"  is  not  the  same  as  taking  a  copyright 
by  assignment  or  bequest.  What  the  DoD  "special  works"  clause  will  be  effective  in  doing  is 
precluding  the  contractor  from  claiming  any  ownership  rights  in  the  software.  If  the  Defense 
Department  wishes  to  obtain  a  copyright  interest  in  software,  it  would  be  well-advised  to  adopt  a 
strategy  similar  to  that  adopted  by  NASA  and  that  proposed  under  the  new  FAR. 

5.1  Assignment  of  Copyrights:  The  NASA  and  FAR  Approaches 

NASA  lawyers  with  whom  we  spoke  questioned  the  validity  of  the  DoD  approach  to  taking 
copyrights,  and  offered  their  strategy  as  an  alternative  possibility.  The  NASA  strategy  attempts  to 
take  advantage  of  the  explicit  exception  contained  within  Section  105  which  allows  the  govern¬ 
ment  to  hold  a  copyright  transferred  to  it  by  assignment.  When  NASA  wants  a  copyright  interest 
in  software,  it  inserts  a  special  works  clause  in  the  development  contract  which  requires  the 
contractor  to  obtain  a  copyright  registration  for  the  work  (such  as  software)  and  then  to  assign  the 
copyright  to  NASA  ( [64]  secs.  1827.473-3  and  1852.227-77). 

The  recently  proposed  FAR  has  a  somewhat  more  complicated  approach  to  the  “special  works" 
problem  than  does  the  NASA  policy.  Under  the  allocation  of  rights  provision  of  the  FAR  special 
works  clause,  the  government  claims  four  things:  (1)  unlimited  rights  in  all  data  (which  includes 
software  and  technical  data)  delivered  under  the  contract  and  in  all  data  first  produced  in  perfor¬ 
mance  of  the  contract  (2)  the  right  to  limit  the  contractor’s  exercise  of  claims  to  copyright  data  first 


produced  in  performance  of  the  contract,  (3)  the  right  to  obtain  an  assignment  of  copyright  in  such 
data,  and  (4)  the  right  to  limit  the  release  and  use  of  certain  data  by  the  contractor  (See  [66]  Sec. 
52.227-1 7(b)()(1)). 

One  of  the  two  key  features  of  the  FAR  special  works  clause  is  the  explicit  agreement  it  demands 
from  the  contractor  not  to  assert  a  claim  of  copyright  in  any  data  first  produced  under  the  contract 
without  the  written  permission  of  the  oontract  officer  ( [66]  sec.  52.227.17(c)).  The  second  key 
feature  is  the  power  given  to  the  contract  officer  to  direct  the  contractor  to  claim  copyright  in  such 
data  and  assign  the  copyright  to  the  government  or  its  designated  assignee.  (Id.)  A  further 
interesting  feature  of  the  FAR  clause  is  the  limitations  it  puts  on  the  contractor's  own  use  of  data 
first  produced  under  the  government  contract.  The  contractor  under  the  special  works  clause 
agrees  not  to  use  the  data  for  purposes  other  than  performance  of  the  contract  and  not  to 
release,  reproduce,  distribute,  or  publish  the  data  without  the  written  permission  of  the  contract 
officer. 

If  ownership  and  control  of  certain  software  is  what  the  Defense  Department  thinks  it  needs,  the 
Department  would  be  well-advised  to  pursue  a  strategy  similar  to  that  reflected  in  the  new  FAR. 

5.2  The  Implications  of  Owning  a  Copyright 

There  are  two  differences  in  the  nature  of  the  copyright  protection  afforded  to  those  who  take 
copyrights  by  assignment  and  those  who  own  copyrights  directly.  A  copyright  obtained  through 
assignment  can  be  taken  back  by  the  author  after  a  period  of  35  years  ( [59]  sec.  203(a)(3)).  This 
provision  was  meant  to  protect  improvident  artists  who  might  have  signed  away  their  rights  “for  a 
song"  before  the  value  of  their  product  had  been  recognized.  Thus,  the  government  might  obtain 
less  than  the  full-term  of  copyright  protection  (generally,  75  years)  which  would  be  available  if  it 
could  take  a  copyright  directly.  Still,  a  more  limited  form  of  ire'lectual  property  protection  is 
certainly  preferable  to  a  form  of  protection  which  may  be  unenforceaole;  and,  at  any  rate,  35 
years  is  generally  a  more  than  sufficient  length  of  protection  due  to  the  typically  rapid  obsoles¬ 
cence  of  software. 

Secondly,  to  make  an  assignment  of  a  copyright  effective  against  a  third  party,  it  must  be 
recorded  in  the  Copyright  Office.  Without  recording,  the  assignment  to  the  government  might 
have  to  yield  to  a  subsequent  assignment  to  a  purchaser  in  good  faith  ( [59]  sec.  205(e)).  In 
addition,  proper  recordation  of  the  transfer  of  copyright  is  a  prerequisite  to  the  ability  to  bring  an 
infringement  action  ( [59]  sec.  205(d)).  It  would  thus  be  important  for  the  government  to  take  this 
step  and  see  that  the  assignment  is  recorded  with  the  Copyright  Office. 

5.3  A  Need  for  Legislative  Reform? 

It  is  interesting  to  note  that  the  U.S.  Government  is  permitted  to  take  patent  rights  directly,  but  not 
copyrights.  Congress  appears  to  have  two  principal  reasons  for  prohibiting  copyright  protection 
for  “works  of  the  United  States  Government.'  If  the  Defense  Department  regards  being  able  to 
take  direct  copyright  interests  in  software  as  sufficiently  important  to  seek  special  dispensation 


from  Congress,  these  two  reasons  can  be  turned  around  and  used  to  construct  a  rationale  for  a 
software  exception  to  the  general  rule  against  copyright  ownership. 

5.3.1  The  Double  Subsidy  Argument 

One  concern  evident  in  the  legislative  history  of  Section  105  was  that  the  public  would,  in  effect, 
be  paying  a  double  subsidy  for  the  work  if  the  government  were  permitted  to  obtain  copyright 
protection  in  works  produced  at  public  expense  —  first  in  the  form  of  tax  dollars  spent  to  develop 
the  work,  and  then  in  the  form  of  the  higher  prices  which  would  be  generated  by  the  commercial 
advantage  of  copyright  protection. 

This  rationale  for  the  Section  105  prohibition  does  not  explain  why  Congress  decided  to  treat 
government  ownership  of  copyrights  and  patents  differently.  The  same  double  subsidy  concerns 
would  seem  to  exist  for  patentable  works  produced  at  public  expense.  In  either  case,  the  public 
is  paying  twice  if  forced  to  1)  support  the  development  of  the  work  with  tax  dollars,  and  2)  then 
pay  a  higher  price  for  access  to  the  work  due  to  the  commercial  advantage  generated  by  a 
particular  form  of  intellectual  property  protection.  Perhaps,  therefore,  the  double  subsidy  ar¬ 
gument  does  not  seem  to  have  been  Congress’  primary  concern. 

One  can  turn  the  double  subsidy  concern  around  by  pointing  out  that  there  may  sometimes  be  a 
strong  need  for  the  government  to  have  a  copyright  to  accomplish  its  objectives  for  software 
produced  at  public  expense.  It  may  sometimes  need  the  power  to  control  uses  that  other  firms, 
including  the  contractor  that  originally  produced  the  software,  may  make  of  the  software,  and 
may,  in  particular,  need  to  be  able  to  control  the  preparation  of  derivative  works.  To  insure  that 
the  government  will  not  have  to  pay  again  for  the  privilege  of  exercising  such  control,  allowing  the 
government  to  own  the  intellectual  property  interest  may  be  important.  If  private  industry  is  to  be 
permitted  always  to  retain  ownership  interests  in  software  developed  at  public  expense,  the  result 
will  likely  be  greater  expenditure  of  funds  by  the  government  and  by  the  public  at  large  ~  that  is,  a 
greater  subsidization  by  the  public  -  a  result  which  runs  counter  to  the  policies  underlying  Section 
105  of  the  Copyright  Act.  The  government  could  use  such  an  argument  in  an  effort  to  bring  about 
legislative  reform  of  the  Copyright  Act  so  as  to  provide  a  software  exception  from  the  Section  105 
prohibition. 

5.3.2  The  Free  Flow  of  Information  Argument 

The  other  major  reason  for  the  prohibition  against  government  ownership  of  copyrights  explains 
why  there  is  a  differential  treatment  as  to  patents  and  copyrights.  The  legislative  history  of  Sec¬ 
tion  105  and  its  predecessor  Section  8  of  the  previous  Copyright  Act  speak  of  an  intent  to  place 
"all  works  of  the  United  States  Government,  published  or  unpublished,  in  the  public  domain,"  and 
of  the  need  to  have  works  "freely  available"  ( [6]  pp  58).  Indeed,  the  most  cited  case  dealing  with 
the  prohibition  against  copyright  for  government  works  (Public  Affairs  Associates,  Inc.  v.  Rick- 
over  [42])  looked  primarily  to  such  free  flow  of  information  concerns  in  determining  the  scope  of 
this  prohibition.  As  the  court  stated  in  Rickover  ( [42]  pp  268)  the  prohibition  against  the  U.S. 
Government  securing  copyright  protection  for  works  developed  at  public  expense  "is  designed  to 


achieve  in  a  democracy  that  depends  upon  accurate  public  knowledge  the  broadest  publicity  for 
matters  of  government."  The  concerns  expressed  in  the  Rickover  case  relate  to  censorship  and 
freedom  of  information.  These  concerns  provide  a  justification  for  prohibiting  government  acquisi¬ 
tion  of  copyright  protection  for  works  developed  at  public  expense,  and  are  also  consistent  with 
the  differential  treatment  accorded  patentability  of  inventions  developed  at  public  expense  (in 
which  case  concerns  over  free  flow  of  information  and  the  potential  for  censorship  would  not  be 
as  pronounced). 

Software  would  seem  to  fit  more  appropriately  within  the  rationale  for  allowing  exclusive  rights 
protection  in  the  area  of  inventions  than  for  precluding  such  rights  for  the  government  in  the  area 
of  copyrightable  subject  matter.  Software  would  not  seem  to  raise  the  same  kinds  of  "free  flow  of 
information"  and  "right  of  the  public  to  know"  concerns  which  underlie  the  differential  treatment 
accorded  "works  of  the  United  States  Government"  of  a  traditional  copyrightable  sort  as  opposed 
to  works  which  involve  patentable  subject  matter. 

Software  is  a  tool  for  performing  a  job;  it  is  a  commercial  item,  not  a  communicative  one  (at  least 
not  in  the  censorship/free  flow  of  information  sense  of  that  term).  The  commercial  realities  of  the 
software  industry  make  K  highly  desirable  for  the  government  be  able  to  protect  its  interests  in  this 
area.  The  issue  is  not  one  of  censorship,  but  one  of  rational  use  of  public  funds.  The  public 
benefit  from  a  "free  flow"  of  the  "information"  contained  in  software  seems  less  strong  than  in  the 
case  of  books  and  articles.  Given  that  the  public  is  likely  to  pay  more— in  the  form  of  higher 
expenditure  of  tax  dollars— for  this  dubious  privilege,  the  rationale  for  treating  software  the  same 
as  other  copyrighted  works  seems  weak. 

The  policies  of  the  Section  105  prohibition  against  copyright  protection  for  "works  of  the  United 
States  Government"  simply  do  not  fit  in  the  case  of  software  developed  at  public  expense,  and 
actually  seem  to  be  undermined  by  such  an  application  of  this  provision. 

5.4  Conclusion 

There  do  seem  to  be  some  circumstances  in  which  government  ownership  of  rights  in  software 
would  be  desirable.  Strict  application  of  the  copyright  law  does  not  provide  adequate  intellectual 
property  protection  for  software  developed  at  public  expense.  A  protection  scheme  more  akin  to 
that  provided  under  the  patent  laws  may  be  needed  to  adequately  protect  the  government’s 
legitimate  interests  in  software  developed  at  government  expense.  At  the  very  least,  an  excep¬ 
tion  from  the  Section  105  prohibition  against  copyright  could  be  argued  for  on  these  grounds. 
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6.  Problems  Arising  from  the  Government  Trademark  Rights  as 
Regards  Software 


In  recent  years  the  Defense  Department  has  been  acquiring,  maintaining,  and  enforcing 
trademark  rights  in  words  used  in  connection  with  software  (among  them,  in  "Ada").  We  have  not 
had  an  opportunity  to  see  the  government's  trademark  registration  certificate  or  to  thoroughly 
investigate  the  trademark  questions  discussed  below.  However,  because  "Ada"  and  other  similar 
trademarks  seem  to  be  important  to  the  government  and  because  interviews  with  DoD  personnel 
seemed  to  reveal  some  misconceptions  about  trademark  issues  (and  about  the  perils  of  not  being 
careful  about  use  of  trademarks)  it  seemed  that  these  concerns  needed  to  be  raised.  They  seem 
deserving  of  further  study. 

6.1  What  Kind  of  Mark  Does  the  Government  Own? 

A  question  which  we  put  to  several  government  people  who  seemed  knowledgeable  about  the 
"Ada"  trademark  was  what  kind  of  a  mark  it  is:  a  trademark  or  a  certification  mark?  There  are 
important  differences  between  the  two,  and  some  important  limitations  on  rights  depending  on 
what  kind  of  mark  it  is.  The  government  people  to  whom  the  we  spoke  seemed  not  to  know  what 
kind  of  mark  "Ada"  was. 

6.1 .1  What  a  Trademark  Is 

A  trademark  is  a  word,  picture,  or  symbol  which  a  manufacturer  or  seller  of  goods  adopts  and 
affixes  to  his  products  in  order  to  identify  that  manufacturer  or  seller’s  goods  and  distinguish  them 
from  others'  goods  ( [63]  sec.  1 127).  ("Kellogg’s,*  for  instance,  is  a  trademark  for  cereal  products, 
which  the  mark's  owner  stamps  on  the  box  to  allow  consumers  to  discern  that  this  box  of  cereal 
was  made  by  Kellogg,  and  not  by  another  cereal  manufacturer.)  Trademark  law  is  aimed  at 
protecting  consumers  from  being  confused,  not  at  protecting  the  valuable  property  right  the  owner 
of  the  mark  may  have  or  thinks  he  has  in  the  mark.  To  serve  a  trademark  function,  a  word  or 
other  symbol  cannot  be  a  functional  part  of  the  product,  and  it  has  to  signify  to  consumers  from 
whom  the  goods  come,  not  what  kind  of  goods  they  are. 

6.1 .2  What  a  Certification  Mark  Is 

Trademarks  can  only  be  owned  by  persons  who  manufacture  or  distribute  goods  bearing  that 
particular  mark.  By  contrast,  the  owner  of  a  certification  mark  is  prohibited  from  being  either  a 
manufacturer  or  distributor  of  goods  for  which  certification  is  sought.  Unlike  a  trademark,  a  cer¬ 
tification  mark  does  not  signify  the  source  of  goods;  it  signifies  only  that  certain  goods  have  met  a 
certain  standard.  A  certification  mark,  then,  is  a  mark  used  upon  or  in  connection  with  the 
products  of  one  or  more  persons  other  than  the  owner  of  the  certification  mark  which  certifies  one 
or  more  of  the  following:  regional  or  other  origin,  material,  mode  of  manufacture,  quality,  ac¬ 
curacy,  or  other  characteristics  of  the  products  ( [63]  sec.  1127.) 
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To  obtain  rights  to  a  certification  mark,  one  must  register  the  mark  with  a  federal  agency  and  set 
forth  the  criteria  an  applicant  must  satisfy  to  be  certified  to  use  the  mark.  The  certification  mark 
owner  is  obligated  to  apply  the  standards  in  a  non-discriminatory  fashion  to  those  who  seek 
certification.  A  certification  mark  is  subject  to  cancellation  or  to  a  challenge  to  its  validity  in 
infringement  litigation  if: 

(1 )  the  owner  of  it  has  not  controlled  or  is  unable  legitimately  to  control  use  of  the  mark, 

(2)  has  started  reproducing  or  marketing  any  goods  to  which  the  certification  mark  is  applied, 

(3)  has  permitted  use  of  the  certification  mark  for  other  than  certification  purposes,  or 

(4)  has  discriminatorily  refused  to  certify  or  continue  to  certify  the  product  of  any  person  who 
meets  the  standards  which  the  mark  certifies  ( [63]  sec.  1 064(e)). 

A  certification  mark  will  also  be  subject  to  cancellation  if  it  is  (or  has  become)  a  generic  or 
common  descriptive  name  for  a  kind  of  produd  ([63]  sec.  1064(c)).  Even  having  an 
"incontestable"  mark  will  not  preclude  cancellations  on  these  grounds  ( [63]  sec  1065). 

The  important  -  if  obvious  --  point  here  is  that  either  one  has  a  trademark  or  one  has  a  certifica¬ 
tion  mark.  One  cannot  have  both,  at  least  not  as  to  the  same  or  similar  kind  of  goods  ( [7]  sec. 
19:32).  While  "Good  Housekeeping"  is  a  trademark  as  to  a  magazine  and  a  certification  mark  as 
to  various  household  goods,  there  is  a  large  gap  between  these  two  things.  Where  the  gap  is 
narrower  or  non-existent,  certification  marks  may  be  invalid  if  similar  to  a  preexisting  trade  mark 
already  owned  by  the  applicant.  (See  In  Re  Florida  Citrus  Company  [32]).  And  if  one  has  a 
certification  mark,  one  cannot  at  the  same  time  be  the  producer  or  distributor  of  goods  of  the 
same  kind. 

6.1.3  What  Is  "Ada"? 

The  government  has  established  rigorous  standards  that  must  be  met  before  a  compiler  can  be 
certified  as  an  "Ada  compiler."  It  seems  reasonable,  therefore,  to  assume  that  the  kind  of  mark 
government  must  have  in  "Ada"  is  a  certification  mark  for  use  in  connection  with  compiler 
programs.  If  this  assumption  is  correct,  then,  in  accordance  with  the  principles  set  forth  in  the 
previous  subsection,  it  is  clear  that  the  government,  in  order  to  maintain  the  certification  mark, 
must  not  take  ownership  rights  in  any  software  using  the  mark.  It  must  police  use  of  the  mark  by 
non-certified  parties.  It  must  make  sure  that  the  mark  is  not  used  for  other  than  certification 
purposes.  And  it  must  not  deny  certification  to  qualified  parties.  If  “Ada"  is  intended  to  be  a 
certification  mark  for  things  other  than  compiler  programs,  the  government  should  make  sure  its 
registration  for  "Ada"  is  broad  enough  to  cover  these  other  things  and  the  government  must 
develop  standards  and  guidelines  for  other  such  "Ada"  products. 
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6.2  Who  Owns  the  Ada  Trademarks? 

"Ada"  is  most  often  advertised  as  "a  registered  trademark  of  the  U.S.  government"  or  as  "a 
registered  trademark  of  the  U.S.  Department  of  Defense."  (The  AJPO  Guidelines  the  govern¬ 
ment  has  issued  for  use  of  the  Ada  trademark  are  of  the  latter  type.)  When  we  asked  DoD 
people  about  the  potential  problem  of  the  government  owning  programs  that  might  be  within  the 
range  of  its  certification,  thereby  endangering  any  certification  mark  it  might  have,  the  response 
was  that  it  is  really  the  Ada  Joint  Program  Office  (AJPO)  that  owns  the  Ada  mark. 


However,  the  government  itself  widely  touts  the  Ada  mark  as  being  owned  by  the  government  or 
DoD.  Because  of  this,  it  is  conceivable  that  a  court  would  find  an  overlap  of  ownership.  Further¬ 
more,  because  a  court  would  be  unlikely  to  enforce  a  certification  mark  owned  by  one  division  (or 
even  a  subsidiary)  of  a  company  that  certified  the  products  of  another,  it  is  not  clear  that  even  if 
AJPO  is  found  to  be  the  legal  owner,  it  is  separate  enough  from  another  unit  of  DoD  for  the 
certification  mark  to  stand.  At  any  rate,  it  would  seem  prudent,  if  this  is  to  be  DoD’s  defense,  to 
start  touting  Ada  as  being  owned  by  the  AJPO,  or  to  make  sure  DoD  never  takes  ownership  in 
any  Ada  software  as  a  protective  measure. 


6.3  What  is  the  Scope  of  the  Mark  in  "Ada"? 

Just  because  the  government  might  property  own  a  certification  mark  in  Ada  as  to  compilers,  that 
doesn't  necessarily  mean  it  owns  rights  in  Ada  across  the  board,  or  even  as  to  anything  relating 
to  software.  The  point  is  not  an  obvious  one,  and  may  run  counter  to  what  common  sense  might 
suggest,  but  the  way  trademark  theory  runs,  when  someone  acquires  rights  in  a  mark,  he  only 
has  the  right  to  use  that  mark  in  connection  with  sale  of  the  particular  goods  publicly  distributed 
with  use  of  the  mark.  Someone  else  is  free  to  use  the  same  mark  in  connection  with  the  sale  of 
another  kind  of  goods.  The  reason  is  that  consumers  won’t  be  confused  if  they  see  the  same 
mark  on  different  kinds  of  goods.  (If  you  see  the  word  "Tiffany’s"  on  a  can  of  tobacco,  you  won’t 
think  the  famous  jeweler  made  it.) 


6.3.1  Is  "Ada"  Generic? 


The  Guidelines  written  by  the  AJPO  about  use  of  the  trademark  Ada  state  (at  sec.  1(b)): 


It  is  fundamented  [sic]  important  that  the  Ada  trademark  [sic]  not  become  a  generic  name  for  a 
class  of  programming  languages;  and  that  it  be  well  understood  that  the  Ada  trademark  refers  to 
one  programming  language,  created  by  DoD,  whose  purity  is  maintained  through  a  rigorous 
language  control  mechanism. 


Unfortunately,  there  may  not  be  anything  the  sjovemment  can  do  to  prevent  Ada  from  being  found 
to  be  a  generic  term  for  the  computer  programming  language  as  to  which  it  is  commonly  used. 
The  trademark  law  tests  genericness  based  on  what  the  ordinary  person  would  think  the  term 
referred  to,  not  what  the  owner  of  the  mark  thinks.  The  primary  significance  of  "Ada*  would  seem 
to  be  as  a  particular  language,  rather  than  as  signifying  DoD  as  the  source  of  some  product,  if  it 
is,  the  term  would  seem  to  be  generic  to  that  extent. 
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Ada  is  less  likely  to  be  found  generic  as  to  computer  programs  (or  compilers).  To  the  extent  that 
the  DoD  wants  to  assert  trademark-type  rights  to  "Ada"  in  conjunction  with  computer  programs,  it 
may  (if  careful)  be  able  to  maintain  some  control  over  the  term. 

6.3.2  The  Scope  of  the  Government’s  Rights  In  "Ada"  as  to  Compilers 

Assuming  that  DoD  owns  a  valid  certification  mark  in  Ada  as  to  compilers  that  meet  its  rigorous 
set  of  prescribed  standards,  DoD  not  only  can  authorize  those  who  meet  the  standards  to  adver¬ 
tise  their  products  as  "certified  as  Ada  compilers,"  it  must  police  the  market  to  insure  that  others 
are  not  marketing  uncertified  products  as  if  they  were  certified.  But  this  duty  can  be  over- 
zealously  enforced.  Owning  a  certification  mark  in  Ada  does  not  necessarily  mean  the  govern¬ 
ment  has  a  right  to  prevent  anyone  who  has  produced  a  compiler  that  is  capable  of  compiling  Ada 
source  code  into  machine  code  from  making  reference  to  "Ada"  in  promotional  materials  for  the 
program.  DoD  would  have  a  right  to  control  who  can  promote  their  products  as  "certified  as  an 
Ada  compiler."  However,  this  does  not  mean  that  DoD  can  stop  someone  from  saying  "this 
program  compiles  Ada."  There  is  such  a  thing  as  a  fair  use  defense  to  trademark  infringement 
actions.  Under  15  U.S.C.  sec.  1 1 15(b)(4)  [63]  persons  are  entitled  to  use  words  that  other  people 
claim  as  marks  if  they  do  so  in  good  faith  and  in  order  to  accurately  describe  their  product.  The 
latter  comment  above  would  appear  to  fall  within  the  fair  use  defense. 

6.3.3  The  Scope  of  the  Government’s  Rights  in  "Ada"  as  to  Other  Programs 

From  perusing  the  AJPO  Guidelines  for  the  use  of  Ada,  it  appears  that  DoD  is  claiming  rights  to 
control  use  of  the  term  "Ada"  in  conjunction  with  programs  other  than  compilers.  However,  these 
guidelines  only  set  forth  standards  that  must  be  met  by  compilers.  If  the  government  wishes  to 
certify  other  kinds  of  programs,  it  would  need  to  have  and  publish  standards  for  those  other 
things.  And,  of  course,  the  government’s  mark  as  to  other  programs  would  also  be  subject  to  a 
fair  use  defense. 

6.3.4  The  Scope  of  the  Government's  Rights  as  to  References  to  "Ada"  in 
Publications 

Many  trademark  owners  whose  marks  are  endangered  because  of  widespread  usage  of  the  term 
in  a  generic  way  (Xerox,  Kleenex,  and  plexiglass  come  to  mind)  have  undertaken  a  policy  to 
protect  the  source  significance  of  the  mark  by  highlighting  its  trademark  significance.  This  may 
include,  in  the  mark  owner’s  own  promotional  materials,  use  of  a  "TM"  or  "(R)’  or  "brand"  placed 
next  to  the  endangered  mark;  it  may  also  include  the  mark  owner’s  request  (or  even  demand)  to 
others  who  might  make  reference  to  the  mark,  that  they  acknowledge  the  mark  as  a  trademark  in 
some  way  (e.g.,  use  of  "TM"  next  to  the  word).  A  trademark  owner  does  not,  however,  have  a 
legally  enforceable  right  to  insist  on  reference  to  the  mark  as  a  mark  in  connection  with  written 
materials  (other  than  advertisements).  The  only  thing  that  invades  a  trademark  owner’s  rights  is 
use  of  the  mark  by  a  competitor  or  near  competitor  in  a  way  that  would  confuse  consumers. 
Reference  to  a  mark  in  a  book  or  article  does  not  fall  into  that  category.  That  isn't  to  say  that  DoD 


should  not  encourage  others  to  respect  their  rights  in  "Ada,"  but  it  is  to  say  one  should  be  careful 
to  understand  the  limits  the  law  of  trademarks  places  on  an  owner's  rights. 

6.4  Conclusion 

We  would  caution  DoD  to  be  careful  about  its  use  and  its  authorization  of  other's  use  of  the  term 
"Ada"  for  other  than  certification  purposes.  Recall  that  this  is  one  of  the  grounds  for  cancellation 
of  a  mark. 

What  DoD  is  attempting  to  do  in  promoting  Ada  as  a  standard  programming  language  and  in 
developing  high  standards  for  certifying  programs  written  in  and  for  that  language  are  laudable 
aims.  We  would  hope  these  aims  are  realized  and  only  wish  to  caution  about  the  care  that  must 
be  employed  in  using  trademark  law  to  achieve  them.  We  would  not  want  to  see  the 
Department's  own  lack  of  experience  with  trademarks  become  the  basis  for  undermining  the 
achievement  of  these  worthy  goals. 


7.  A  Hypothetical  Illustration  of  Software  Licensing  Problems  under 
the  Existing  Regulations 

The  Defense  Department  has  recently  undertaken  the  funding  of  some  ambitious  software  en¬ 
gineering  projects.  It  therefore  seems  worthwhile  to  examine  a  set  of  licensing  problems  and 
questions  that  are  likely  to  arise  in  connection  with  such  projects.  Many  of  the  problems  which 
will  be  discussed  in  this  chapter  have  been  discussed  in  previous  chapters  in  a  more  abstract 
way.  This  chapter  presents  a  hypothetical  situation  which  may  provide  a  useful  illustration  of  how 
these  abstract  problems  might  evidence  themselves  in  a  concrete  instance. 

Although  the  discussion  below  is  hypothetical,  it  is  important  to  understand  that  any  ambitious 
software  project  of  the  sort  presented  here  could  raise  similar  problems.  To  solve  these  problems 
now,  before  they  erupt  into  litigation,  would  seem  desirable. 

7.1  The  Hypothetical  Situation 

For  purposes  of  this  illustration,  assume  that  the  DoD  has  made  a  major  funding  commitment  with 
a  contractor  (Contractor  A)  for  the  development  of  an  extremely  sophisticated  software  system 
(We’ll  call  it  Z  System).  The  primary  objectives  of  the  Z  System  contract  are  as  follows: 

(1 )  the  development  of  a  standard  set  of  software  development  tools  that  the  government  could 
use  for  the  purpose  of  generating  code  for  military  purposes; 

(2)  dissemination  of  this  standard  tool  set  to  the  defense  contractor  community  for  the  purpose 
of  use  in  military  projects; 

(3)  excellence  in  the  tool  set  so  that  the  industry  would  want  to  use  the  tool  set  rather  than 
having  to  be  required  to  use  it; 

(4)  creation  of  many  derivative  works,  most  obviously  "rehosts"  (rewriting  the  Z  System  so  that 
it  will  operate  on  different  host  machines)  and  "retargets*  (altering  the  Z  System  so  that  it  will 
produce  code  that  will  run  on  different  machines),  ail  of  which  would  be  widely  available  to  the 
government  and  to  industry; 

(5)  creation  of  commercial  spinoffs  by  those  who  might  rehost  or  retarget  (which  hopefully 
would  give  those  firms  some  incentive  to  create  a  good  product  for  the  government);  and 

(6)  control  over  exports  of  the  standard  tool  set. 

To  get  this  project  underway,  the  DoD  might  let  a  contract  to  Contractor  A  to  develop  the  Z 
System  to  run  on  one  particular  "host"  computer  and  to  produce  code  which  would  run  on  another 
particular  "target"  machine.  It  might  well  be  understood  that  the  first  version  of  the  Z  System 
would  serve  as  a  model  for  future  developments  of  rehosts  and  retargets,  and  that  the  original 
would  not  itself  be  as  widely  used  to  generate  code  as  the  derivatives  because  it,  for  example, 
might  have  been  written  to  run  on  a  mainframe,  whereas  most  of  the  uses  would  be  for 
microcomputers.  Assume  also  that  a  large  sum  of  money,  somewhere  in  the  range  of  $20  mil¬ 
lion,  has  been  paid  to  Contractor  A  for  the  Z  System  product,  a  version  of  which  has  been 
delivered. 


The  question  the  government  needs  to  know  is:  What  is  the  extent  of  the  government’s  rights  in 
the  Z  System. 

7.2  Government  Takes  Unlimited  Rights,  or  Does  it? 

In  most  software  development  contracts,  DoD  will  have  used  the  standard  data  rights  clause 
( [61]  sec.  52.227-7013).  Assuming  this  was  done  in  the  contract  with  Contractor  A  for  the  Z 
System,  the  government’s  normal  expectation  would  be  that  since  public  funding  would  subsidize 
the  development  costs,  the  government  would  have  unlimited  rights. 

Now  suppose  for  purposes  of  this  hypothetical,  that  to  the  surprise  and  dismay  of  the  DoD,  the  Z 
System  software  and  documentation  is  delivered  to  DoD  with  Contractor  A’s  copyright  notice 
affixed  to  it.  None  of  the  DoD  procurement  personnel  who  let  the  Z  system  contract  may  have 
noticed  the  part  of  the  standard  data  rights  clause  that  permits  contractors  to  retain  copyright 
interests  in  all  works  delivered  to  the  government  (except  those  delivered  as  "special  works.") 

The  reader  should  recall  that  the  effect  of  the  contractor’s  copyrighting  a  work  paid  for  by  the 
government  seems  to  be  that  the  government  will  get  a  license  to  copy  and  use  the  work  for 
governmental  purposes.  Because  the  clause  was  ambiguous  and  was  drafted  by  DoD,  a  court 
would  likely  find  the  copyright  retention  clause  to  limit  the  extent  of  the  government’s  rights.  That 
this  might  perturb  the  expectations  of  DoD’s  procurement  personnel  who  thought  that  the  govern¬ 
ment  would  have  unlimited  rights  is  unfortunate,  but  not  contractor  A’s  problem. 

If  DoD  decided  to  attempt  to  purchase  the  copyright  from  Contractor  A,  Contractor  A  would  most 
likely  realize  that  the  government  was  in  a  poor  bargaining  position  and  would  take  advantage  of 
the  situation  by  offering  to  sell  the  copyright  for  what  the  DoD  would  consider  to  be  an  outrageous 
sum. 

7.3  Rehosts,  Retargets,  and  Enhancements  of  the  Z  System 

It  is  important  to  understand  how  the  cutback  from  unlimited  rights  to  governmental  purpose 
rights  might  limit  the  government's  power  to  achieve  its  objectives  for  Z  system.  The  clearest 
example  of  a  likely  source  of  friction  would  arise  in  the  creation  of  derivative  software.  We  have 
assumed  that  the  government  always  intended  to  authorize  rehosts  and  retargets  to  be  made  of 
the  Z  System  and  that  Contractor  A  would  not  be  the  sole  source  for  all  these  derivative  works. 
Contractor  A,  in  this  hypothetical,  would  likely  not  contest  the  government’s  right  to  distribute  the 
Z  System  for  the  purpose  of  having  rehosts  and  retargets  prepared  for  it. 

But  what  Contractor  A  may  wish  to  contest  is  the  right  of  the  government  to  make  certain  kinds  of 
deals  to  get  rehosts  and  retargets  made  for  them.  Further,  Contractor  A  may  well  claim  rights  in 
derivative  works  of  the  Z  System  done  by  other  firms.  If  firms  developing  the  derivatives  attempt 
either  to  distribute  the  Z  System  or  derivative  works  of  the  Z  System  for  commercial  purposes, 
Contractor  A  might  challenge  their  rights  to  do  so.  The  government  itself  might  be  concerned 
about  what,  if  any,  rights  it  might  have  in  rehosts  or  retargets  done  by  Contractor  A  for  entities 
other  than  the  DoD.  These  problems  are  explored  in  detail  below. 


7.3.1  Retargeting  or  Rehosting 

Suppose  that  DoD  announced  the  availability  of  the  Z  System  for  rehost  and  retarget  purposes  if 
a  firm  could  meet  certain  minimal  conditions  (e.g.,  having  a  certain  kind  of  computer).  The  DoD 
might  hope  to  get  rehosts  and  retargets  of  the  Z  System  to  be  made  at  minimal  or  no  additional 
cost  to  the  government.  If  the  Z  System  had  considerable  commercial  potential,  the  DoD  might 
hope  that  this  would  serve  as  an  incentive  for  firms  to  do  rehosts  or  retargets  for  the  government 
at  minimal  cost.  The  DoD  would  realize  that  incentives  would  be  enhanced  K  the  firms  were  able 
to  retain  exclusive  commercial  rights  to  their  version  of  the  Z  System. 

Suppose  that  a  computer  company  (Contractor  B)  offered  to  create  a  version  of  the  Z  System  for 
Contractor  B  machines  at  no  charge  to  the  government  on  condition  that  Contractor  B  would 
retain  all  commercial  rights  to  their  version  of  Z.  (Contractor  B  might  think  that  commercial  sales 
of  its  computers  would  be  enhanced  by  being  able  to  offer  its  version  of  the  Z  System  along  with 
the  machine.  Sales  of  Contractor  B's  machines  to  DoD  might,  of  course,  also  be  enhanced.) 
Contractor  B  might  ask  the  DoD  for  assurances  that  Contractor  B  could  do  this  without  any 
liability  to  A.  The  question  is  whether  DoD  can  give  Contractor  B  this  reassurance  on  the  theory 
that  it  is  a  legitimate  governmental  purpose  to  get  a  free  retarget,  and  therefore  within  the 
government’s  rights  vis-a-vis  Contractor  A.  What  happens  if  Contractor  A  expresses  objection  to 
this  kind  of  deal,  as  seems  likely,  arguing  that  its  copyright  in  the  Z  System  gives  Contractor  A  the 
right  to  control  all  commercial  distributions  of  the  derivative  works  of  its  copyrighted  work,  the  Z 
System? 

Preparing  derivative  works  is  one  of  the  exclusive  rights  of  the  copyright  owner  ( [59]  sec.  106(2)). 
The  copyright  statute  defines  "derivative  work"  as  follows  ( [59]  sec.  101): 

a  work  based  upon  one  or  more  preexisting  works,  such  as  a  translation,  musical  arrangement, 
dramatization,  fictionalization,  motion  picture  version,  sound  recording,  art  reproduction,  abridg¬ 
ment,  condensation,  or  any  other  form  in  which  a  work  may  be  recast,  transformed,  or  adapted.  A 
work  consisting  of  editorial  revisions,  annotations,  elaborations  or  other  modifications  which,  as  a 
whole,  represent  an  original  work  of  authorship,  is  a  "derivative  work." 

Both  a  rehosting  and  retargeting  of  the  Z  System  would  seem  to  fit  this  definition. 

Common  sense  might  suggest  that  if  Contractor  B  created  a  retarget  for  the  government  and  the 
creation  of  the  retarget  was  within  the  scope  of  the  government’s  license,  Contractor  B  could  take 
a  copyright  in  the  retarget  (assuming  that  the  government  would  once  again  use  the  standard 
data  rights  clause  in  its  contractual  arrangement  with  Contractor  B).  However,  under  the 
copyright  statute,  it  is  not  clear  that  Contractor  B  is  entitled  to  a  copyright,  or  that  its  copyright 
would  entitle  Contractor  B  to  make  commercial  distribution  of  the  derivative  work.  This  is  be¬ 
cause  Contractor  A’s  permission  to  the  government  to  authorize  the  making  of  derivative  works 
seems,  in  this  hypothetical,  to  be  limited  to  governmental  purposes.  Contractor  A  might  claim 
that  the  terms  of  the  government’s  deal  and  Contractor  B’s  commercial  intent  exceed  the  scope 
of  this  license.  It  is  a  general  rule  of  copyright  law  that  if  one  exceeds  the  scope  of  license 
permission,  an  infringement  of  the  copyright  has  occurred  (e  g.,  Gilliam  v.  American  Broad- 


casting  Co.  [30]).  Also,  copyright  protection  in  a  derivative  work  will  not  attach  to  the  extent  that  it 
unlawfully  incorporates  another  author's  copyrighted  material  ( [59]  sec.  103(a)).  If  the  govern¬ 
ment  (instead  of  Contractor  A)  owned  the  Z  System  copyright,  jt  could  authorize  Contractor  B  to 
copyright  Contractor  B’s  derivative  work.  Not  owning  the  copyright,  the  government  cant  grant  to 
Contractor  B  a  larger  license  than  the  government’s  arrangement  with  Contractor  A  permits. 
Because  of  this,  it  would  not  be  dear  that  Contractor  B  could  copyright  the  retarget  and  distribute 
it  commercially.  As  a  matter  of  copyright  law,  Contractor  A  would  seem  to  have  a  legal  right  to 
control  commercial  distributions  of  the  Contractor  B  version  of  the  Z  System,  although  as  subsec¬ 
tion  7.3.5  within  indicates,  Contractor  A  may  not  itself  have  any  rights  to  use  or  sell  Contractor  B’s 
version  of  the  Z  System. 

7.3.2  Giving  Away  Z  System  Code  for  Commercial  Distribution 

Now  suppose  that  DoD  is  also  in  the  process  of  letting  a  second  contract  for  some  enhancements 
to  the  Z  System  (Z  System-2).  (Suppose  also  that  Contractor  A  will  not  be  a  contender  for  this 
contract.)  As  a  result  of  the  problems  DoD  may  have  had  with  Contractor  A  over  the  original  Z 
System,  assume  that  DoD's  contract  personnel  for  Z-2  try  very  hard  to  structure  their  contractual 
arrangements  with  the  new  contractor  so  as  to  avoid  those  problems.  One  way  to  attempt  this 
might  be  to  try  to  get  government  ownership  of  the  Z-2.  (The  problems  with  this  approach  be 
discussed  below  in  Section  7.5)  Suppose  also  that  part  of  the  RFP  authorizes  the  winner  of  the 
Z-2  contract  to  distribute  the  machine-readable  version  of  Contractor  A’s  Z  System  to  all  of  its 
commercial  customers.  (The  RFP  might  forbid  the  winner  from  selling  Contractor  A’s  version  of 
the  Z  System  code  but  might  purport  to  allow  it  to  distribute  the  Z  System  code  to  commercial 
customers  free  from  the  obligation  to  get  Contractor  A’s  permission  and  free  from  any  obligation 
to  pay  royalties  to  Contractor  A.)  To  the  extent  that  the  Z-2  would  be  a  derivative  work  of  the  Z 
System,  the  RFP  might  also  give  permission  to  the  winning  offer  or  to  sell  or  license  the  derivative 
Z  System  to  its  commercial  customers  free  from  any  obligations  toward  Contractor  A. 

The  interesting  question  is,  of  course,  whether  the  government  has  the  legal  right  to  authorize 
commercial  distributions  of  the  Z  System  code  or  to  authorize  commercial  distributions  of  a 
derivative  work  of  the  Z  System  program  without  Contractor  A’s  (i.e.,  the  original  copyright 
owner’s)  permission.  This,  of  course,  leads  back  to  the  question  of  what  the  scope  of  the 
government's  rights  are  under  the  standard  data  rights  clause. 

7.3.3  Balancing  The  Government's  and  Contractor  A’s  Interests 

The  government  might  argue  that  it  does  have  the  legal  right  to  do  these  things  because  it  is  an 
appropriate  governmental  purpose  to  have  rehosts,  retargets,  and/or  enhancements  of  the  Z 
System  made  at  the  least  cost  to  the  government,  and  for  those  rehosts,  etc.  to  be  widely  avail¬ 
able,  and  Contractor  A  always  knew  that  widespread  dissemination  of  derivative  works  was  in¬ 
tended. 

Contractor  A's  response  might  well  be  that  under  the  copyright  faw,  it  has  rights  over  distributions 
of  its  product  to  commercial  customers  and  over  distributions  of  derivative  products  to  commercial 


customers,  which  rights  the  government  cannot  abrogate  simply  because  it  wants  to.  Contractor 
A  might  well  argue  that  it  is  not  a  legitimate  governmental  purpose  to  authorize  commercial 
distributions  of  its  work,  in  part  because  such  distributions  are  not  directly  in  fulfillment  of  any 
governmental  mission  and  in  part  because  it  undercuts  Contractor  A’s  market  for  the  Z  System  (a 
market  which,  according  to  our  hypothetical,  the  government  agreed  to  leave  to  Contractor  A). 
Contractor  A  might  admit  that  widespread  dissemination  of  the  Z  System  derivatives  was  ex¬ 
pected,  but  might  argue  that  it  would  be  glad  to  license  commercial  marketing  of  those  derivatives 
but  that  it  never  intended  to  leave  itself  with  no  commercial  market.  Contractor  A  might  point  out 
that  the  government  knows  that  there  is  a  very  limited  commercial  market  for  the  original  Z 
System  which  runs  on  a  particular  mainframe  and  prepares  oode  for  another  computer.  Contrac¬ 
tor  A  might  also  aigue  that  the  government  is  under  a  duty  of  good  faith  not  to  destroy  or  under¬ 
mine  the  commercial  market  for  its  Z  System. 

How  a  court  of  law  would  decide  these  matters  is  somewhat  hard  to  predict.  It  is  not,  however,  a 
clear  winner  for  the  government,  or  for  those  whom  the  government  might  wish  to  authorize  to 
make  rehosts,  retargets  and  enhancements. 

7.3.4  What  Rights  the  Government  Has  to  Contractor  A’s  Derivative  Products 

Now  suppose  that  Contractor  A  made  a  deal  with  Contractor  C  to  prepare  a  version  of  the  Z 
System  which  would  operate  on  a  specific  microprocessor.  An  important  question  which  DoD 
should  then  ask  is:  What  if  any  rights  the  government  would  have  in  derivative  works  prepared 
by  Contractor  A  for  others?  If  the  government  had  a  copyright  in  the  Z  System,  or  if  the  govern¬ 
ment  had  unlimited  rights  in  it  and  unlimited  rights  meant  having  ownership  or  an  ownership 
interest,  then  it  would  seem  the  government  would  have  some  rights  as  regards  these  other 
versions  of  the  Z  System.  If  the  government  had  unlimited  rights  (rather  than  a  license  for 
governmental  purposes)  in  the  Z  System,  the  government  might  have  an  argument  that  it  has 
inchoate  rights  in  the  enhancements,  even  though  it  has  no  right  to  possession.  (See  Chapter  1 
for  a  discussion  of  the  problem  of  unlimited  rights  in  non-deliverables.)  Since  it  would  appear  that 
under  this  hypothetical  the  government  may  only  have  a  license  for  governmental  purposes, 
unless  the  government  made  contractual  arrangements  with  Contractor  A  to  obtain  rights  in  all 
derivative  products  prepared  by  Contractor  A,  the  answer  would  seem  to  be  that  it  would  have  no 
rights  to  these  derivative  products. 

7.3.5  Rights  to  Exclude  and  Rights  to  Use 

To  say  that  if  the  government  had  the  copyright  for  the  Z  System,  it  would  have  some  "rights"  as 
against  Contractor  A  when  Contractor  A  prepared  enhanced  versions  of  the  Z  System  for  entities 
other  than  DoD  is  not  to  say  that  the  government  would  own  a  copyright  in  the  enhanced  Z 
System  or  would  even  have  a  right  to  use  copy,  or  disclose  the  enhanced  Z  System  (unless,  of 
course,  by  contract  the  government  had  obtained  such  rights). 

As  Chapter  1  has  shown,  intellectual  property  law  tends  to  define  ownership  rights  in  terms  of 
having  power  to  exclude  others  from  using  the  thing  which  is  claimed  as  property.  A  copyright 


would  give  the  government  the  right  to  prevent  Contractor  A  from  preparing,  copying,  or  distribut¬ 
ing  unauthorized  derivative  works  (such  as  an  enhanced  Z  System).  The  copyright  might  also 
give  the  government  the  right  to  challenge  any  copyright  Contractor  A  might  claim  in  an  enhanced 
Z  System  (recall  that  copyright  protection  is  not  afforded  to  unauthorized  derivative  works).  But 
negative  power  is  not  the  same  as  positive  power.  That  is,  the  power  to  prevent  Contractor  A 
from  making  or  selling  an  unauthorized  enhancement  would  not  entail  a  corresponding  power  on 
the  part  of  the  government  to  employ  the  enhancement  for  itself  (i.e.,  to  use,  disclose,  copy,  or  do 
anything  else  with  it). 

7.3.6  OoD's  Rights  to  Control  Contractor  A’s  Arrangements  with  Other 
Government  Agencies 

In  this  hypothetical,  it  has  been  assumed  that  DoD  obtained  a  license  to  copy  and  use  the  Z 
System  for  governmental  purposes.  This  license  would  not  seem  to  be  restricted  to  the  DoD,  but 
would  seem  to  cover  all  federal  agencies.  It  is  an  interesting  question  whether  Contractor  A  has 
the  right  to  sell  the  Z  System  to  another  governmental  agency,  given  that  the  DoD’s  license  would 
seem  to  mean  that  all  governmental  agencies  are  already  entitled  to  use  it  without  charge. 

Suppose,  for  example,  Contractor  A  sells  rights  to  the  Z  System  to  a  NASA  facility,  at  some 
specified  charge,  and  even  agrees  to  do  some  enhancements  for  NASA.  The  DoD  might  wonder 
whether  Contractor  A  has  a  right  to  do  this  and  whether  DoD  will  be  able  to  get  unlimited  (or  at 
least  license)  rights  to  any  enhancements  that  NASA  might  fund. 

As  to  the  former  question,  it  would  be  somewhat  dependent  on  the  terms  of  the  original  contract, 
but  assuming  that  there  is  no  clause  explicitly  precluding  sales  to  other  governmental  agencies,  it 
is  hard  to  see  on  what  basis  DoD  could  argue  that  Contractor  A  has  no  rights  to  sell  to  NASA  as 
part  of  its  commercial  market  if  NASA  wants  to  buy.  As  to  the  latter  question,  DoD  would  seem  to 
have  no  greater  rights  to  obtain  from  Contractor  A  the  derivative  works  it  prepared  for  another 
government  agency  than  as  to  derivative  works  prepared  for  private  companies.  Perhaps, 
however,  the  DoD  could  obtain  the  enhancements  directly  from  NASA  in  such  a  circumstance. 

7.4  Giving  Out  the  Z  System  to  Industry  for  Other  Than  Rehost/Retarget 
Purposes 

If  DoD  has  only  been  releasing  the  Z  System  to  software  defense  industry  firms  for  the  purposes 
of  having  rehosts  or  retargets  made  for  the  government  to  enable  the  government  to  fulfill  its 
governmental  missions,  this  would  seem  to  be  within  the  scope  of  a  "governmental  purpose" 
license.  But  suppose  the  DoD  decided  instead  to  give  out  the  Z  System  to  the  software  defense 
industry  for  use  by  the  firms  to  produce  code  for  the  government.  Would  that  be  a  valid 
governmental  purpose  within  the  government’s  license  or  would  this  be  an  encroachment  on  the 
commercial  market  rights  of  Contractor  A  under  its  copyright?  It  is  a  close  question.  If  the  sole 
use  that  could  be  made  of  the  Z  System  by  industry  was  in  performance  of  government  contracts, 
that  would  seem  to  be  within  the  scope  of  the  government’s  license.  Simply  to  distribute  the  Z 


System  code  (or  any  improved  version  of  it)  to  defense  industry  because  the  government  thought 
it  best  for  the  industry  to  have  a  good  set  of  standard  tools  would  seem  to  be  stretching 
"governmental  purpose"  further  than  the  government's  right  would  clearly  extend. 

7.5  Taking  a  Copyright  in  a  Derivative  of  the  Z  System  as  a  Way  to  Avoid 
Problems 

Returning  to  the  hypothetical  Z-2  contract,  assume  that  DoD  seeks  to  avoid  the  problems  it  had 
with  Contractor  A  by  putting  a  "special  works"  clause  in  the  RFP  for  the  Z  System-2,  by  which  the 
DoD  hoped  to  take  a  direct  copyright  interest  in  Z-2.  For  reasons  explained  in  Chapter  5,  the 
efficacy  of  the  present  special  works  clause  to  obtain  ownership  rights  for  the  government  is 
questionable  because  of  the  copyright  law’s  preclusion  of  direct  government  ownership  of 
copyrights.  A  special  works  clause  more  like  NASA's  might,  however,  be  effective  in  getting  a 
lawful  copyright  assignment  to  DoD.  Unfortunately,  a  deviation  may  be  required  for  DoD  to  use  a 
clause  other  than  the  special  works  clause  to  achieve  this  purpose. 

The  idea  of  taking  the  copyright  is  a  good  one  because,  if  executed  properly,  a  copyright  will  give 
the  government  rights  to  control  the  making  and  distribution  of  derivative  works.  Had  the  govern¬ 
ment  owned  the  copyright  in  the  Z  System,  Contractor  A’s  version  of  the  Z  System  for  Contractor 
C  would  be  a  derivative  work  in  which  the  government  would  have  rights;  then  it  would  be  Con¬ 
tractor  A’s  copyright  in  the  derivative  work  that  would  be  in  jeopardy  if  Contractor  A  had  not 
obtained  authorization  from  the  government  to  prepare  derivatives. 

Owning  a  copyright  is  a  good  idea,  but  it  has  its  costs,  not  the  least  of  which  is  enforcing  the 
copyright.  Unless  the  government  grants  to  rehost  or  retarget  companies  exclusive  licenses  to 
the  government’s  copyrighted  works,  the  government  will  have  to  be  made  a  party  to  any  lawsuit 
between  the  rehost/retarget  firm  and  one  of  its  customers  over  actions  by  the  customer  in  con¬ 
travention  of  the  rehost/retarget  firm’s  rights  under  the  copyright  license.  (See  3  Nimmer  on 
Copyright  sec.  12.02  [9].)  Also,  being  the  owner  may  make  the  government  a  warrantor  of  the 
software  unless  adequate  disclaimers  have  been  made. 

Some  DoD  people  might  think  that  they  would  be  able  to  free  themselves  from  obligations  to 
Contractor  A  once  they  had  gotten  the  Z  System  rehosted  and  took  a  copyright  in  Z-2  or  Z-3. 
Such  an  assumption  would  be  questionable.  Contractor  A  would  still  be  the  owner  of  a  copyright 
in  the  Z  System  of  which  the  rehost  would  be  a  derivative  work.  The  government’s  power  to  have 
derivatives  made  probably  only  extends  to  having  them  done  for  government  purposes.  Because 
the  government’s  power  will  be  limited  by  the  terms  of  its  license  with  Contractor  A  it  does  not 
become  free  of  that  constraint  simply  by  getting  more  rights  to  a  later  version.  An  analogy  may 
help.  If  you  get  the  permission  of  someone  who  has  translated  a  book  from  French  to  German  to 
use  his  German  translation  to  do  a  translation  into  English,  that  doesn't  mean  that  you  don’t  need 
the  French  author’s  permission  as  well.  Copyright  permissions  must  have  a  clean  trail  back  to 
the  source.  If  you  don’t  get  it,  it’s  like  a  little  tooth  decay  under  a  filling.  The  tooth  goes  on  rotting 
instead  of  being  cured. 


In  other  words,  the  DoD  may  never  be  free  from  obligations  to  Contractor  A  so  long  as  its 
copyrighted  Z  System  is  the  basis  for  the  derivative  programs. 

7.6  What  about  Patents? 

On  the  assumption  that  software  is  not  patentable  and  that  software  algorithms  are  not  patent- 
able,  let’s  suppose  that  the  Z  System  contract  says  nothing  about  allocation  of  patent  rights. 
Although  there  are  certainly  cases  which  say  that  software  and  algorithms  are  not  patentable  and 
other  cases  which  say  that  transformation  of  matter  from  one  physical  state  to  another  is  required 
for  patenting  a  process  that  may  be  implemented  in  software,  it  is  fair  to  say  that  patent  law  as 
regards  software  is  in  a  state  of  flux.  One  important  recent  case  upheld  a  brokerage  firm's  patent 
of  a  data  processing  process  implemented  in  software  (Paine,  Webber,  Jackson  and  Curtis  v. 
Merrill,  Lynch,  Pierce,  Fenner  and  Smith,  [40]).  This  case  could  presage  a  wave  of  non¬ 
manufacturing  process  patents  for  software.  The  government  should  simply  be  aware  of  this 
because  although  patent  ownership  by  a  private  firm  on  software  in  which  the  government  had  a 
copyright  would  not  necessarily  hurt  the  government  in  terms  of  its  own  use  of  the  software,  it 
may  hinder  the  government's  right  to  license  commercial  distributions  of  the  copyrighted  software 
by  other  firms  whom  the  government  might  license  to  use  the  software.  Commercial  distributions 
might  require  getting  permission  from  the  patentee  as  well  as  from  the  government. 

7.7  What  about  Trademarks? 

As  indicated  in  Chapter  6.  the  government  is  more  frequently  taking  ownership  (or  at  least  staking 
out  rights  to)  to  trademarks  in  software  development  contracts.  Assume  a  DoD  RFP  for  some 
system  such  as  Z  system  or  Z  System-2  claims  government  ownership  of  a  trademark  for  the 
system.  There  is  nothing  wrong  with  the  government  trying  to  get  and  enforce  trademark  rights 
so  long  as  it  is  careful  about  what  it  is  doing.  As  Chapter  6  points  out,  trademarks  can  be  very 
tricky;  certification  marks  in  particular  are  subject  to  cancellation  if  one  begins  owning  what  is 
being  certified.  Because  of  this,  guidance  through  a  standard  regulation  about  taking  trademark 
rights  would  seem  to  be  advisable. 

7.8  What  about  Warranties? 

Now  suppose  a  DoD  RFP  is  issued  for  a  software  system  such  as  a  Z  System-2  which  disclaims 
any  warranties  for  the  Z  System  code  that  will  be  "GFI"ed  to  the  winning  bidder.  (Some  govern¬ 
ment  people  seem  to  think  it  unnecessary  to  disclaim  warranties,  arguing  that  everyone  knows 
that  the  government  never  warrants  anything.)  The  Z-2  Contract,  we’ll  assume,  is  is  otherwise 
silent  about  warranties.  As  Chapter  11  explains,  there  is  some  chance  that  implied  warranties  oi 
merchantability  or  fitness  tor  a  particular  purpose  may  attach  to  software;  and  taking  the  copyright 
may  entail  taking  some  responsibility  for  warranties.  Because  of  this,  the  government  should  be 
careful  about  making  sure  that  in  any  distribution  of  the  Z  System  code  (or  a  derivative)  to  any 
commercial  customer  of  the  winning  bidder,  the  government’s  liability  for  warranties  in  that  code 
(as  well  as  in  the  original  Z  System)  be  adequately  disclaimed. 


7.9  Controlling  Export  of  the  Z  System  by  a  Contractor 

Another  potential  problem  regarding  ambitious  software  projects  has  to  do  with  controlling  exports 
of  it.  The  DoD  might  be  very  upset  to  find  out  that  a  Contractor  A  had  licensed  to  export  a  system, 
such  as  the  Z  System,  developed  for  DoD  to  a  foreign  firm. 

The  problem  seems  to  be  that  there  are  presently  two  independent  approaches  for  getting  an 
export  license,  one  handled  by  the  Commerce  Department  under  the  Export  Administration  Act 
( [62]  sec  2401  e]  seo.)  and  one  handled  by  the  State  Department  under  the  Arms  Export  Control 
Act  ( [56]  sec  2751  et  sea.).  We  have  been  told  that  the  former  agency  tends  to  be  somewhat 
more  generous  in  granting  licenses,  being  more  concerned  about  balance  of  trade  than  security 
matters  (although  acquiring  such  a  license  is  still  a  rather  complicated,  onerous  process).  The 
latter  agency  tends  to  be  even  more  cautious  about  granting  licenses,  and  maintains  a  list  of 
arms-related  items  which  cannot  be  exported.  Even  with  caution,  however,  mistakes  can  be 
made. 

Apart  from  the  export  regulations,  it  would  not  seem  that  the  government  would  have  the  power  - 
absent  a  contractual  commitment  not  to  export  without  permission  -  to  prevent  a  contractor’s 
export  of  a  system,  such  as  Z  System,  developed  for  DoD  because  the  standard  data  rights 
clause  is  silent  about  rights  to  control  exports.  Had  the  government  taken  a  copyright  in  the 
system,  it  might  have  a  power  to  prevent  exports  because  exports  are  a  kind  of  distribution  and 
copyright  law  would  give  the  government  the  right  to  exclude  Contractor  A  from  distributing  the 
code  unless  of  course  the  government  had  granted  a  broad  license  to  distribute  the  code  to  the 
contractor. 

7.10  Conclusion 

As  this  chapter  has  illustrated,  software  contracts  raise  a  host  of  difficult  problems  which  current 
regulations  do  not  adequately  address.  To  avoid  these  problems  through  better  planning  would 
be  preferable  to  experiencing  them  again  and  again. 


8.  Subcontractor  Flowdown  Problems 


A  reason  "subcontractor  flowdown"  seems  to  have  been  so  often  raised  by  DoD  personnel  as  a 
software  licensing  problem  is  that  much  software  intended  for  governmental  use  is  developed  at 
the  subcontractor  level.  One  of  the  DoD  persons  whom  we  interviewed  estimated  that  two-thirds 
of  the  mission  critical  computer  resources  (MCCR)  software  prepared  for  DoD  was  developed  by 
subcontractors.  Since  data  rights  and  other  important  aspects  of  the  government's  rights  as 
regards  software  will  depend  at  least  in  part  on  the  arrangements  made  between  the  prime  and 
its  subcontractors,  it  is  not  surprising  that  problems  have  arisen  when  the  arrangement  negotiated 
between  the  government  and  the  prime  differed  from  the  arrangement  between  the  prime  and  its 
subcontractor  (or  even  between  a  first  tier  subcontractor  and  a  second  tier  subcontractor).  Al¬ 
though  other  kinds  of  problems  are  possible,  government  lawyers  tend  to  be  concerned  by  situa¬ 
tions  in  which  the  prime  makes  an  agreement  with  the  subcontractor  to  obtain  lesser  rights  than 
the  government  believes  it  needs  and  had  bargained  for  from  the  prime.  The  examples  we  were 
given  of  "subcontractor  flowdown"  software  licensing  problems  were  of  this  sort. 

What  all  subcontractor  flowdown  problems  have  in  common  is  the  question  of  whether  the 
government  will  be  able  to  enforce  its  contractual  rights  in  the  software  as  against  the  subcontrac¬ 
tor,  or  will  be  able  only  to  sue  (or  gain  concessions  from)  the  prime  for  its  failure  to  deliver  what 
the  government  bargained  for.  Because  such  situations  can  include  second  and  third  tier  sub¬ 
contractors,  and  so  on,  the  questions  raised  can  become  quite  complex  and  difficult  to  sort 
through.  One  project  might  include  several  subcontractors;  it  might  also  include  various  items 
and  components,  each  with  varying  restrictions  on  the  government’s  right  to  use. 

Although  some  of  DoD’s  lawyers  strongly  believe  that  the  government  will  always  be  able  to  get 
the  rights  it  bargained  for  and  insist  that  there  are  no  subcontractor  flowdown  problems,  others 
have  expressed  a  belief  that  the  subcontractor  may  not  be  held  to  an  arrangement  made  by  the 
government  to  which  the  subcontractor  has  not  consented.  In  the  real  world,  the  government 
may  tell  prime  contractors  that  their  failure  to  get  the  rights  they  are  bound  to  deliver  to  the 
government  is  their  (the  prime's)  problem  which  they  have  to  solve  (hopefully  by  getting  the  rights 
the  government  wants),  but  primes  may  realize  that  their  failure  to  get  the  level  of  rights  the 
government  wants  is,  in  reality,  the  government's  problem. 

For  reasons  discussed  below,  this  author  thinks  that  the  government  may  sometimes  be  able  to 
get  the  expected  level  of  rights  from  the  subcontractor  despite  inclusion  of  a  contrary  clause,  and 
sometimes  not.  The  matter  seems  largely  to  turn  on  whether  inclusion  of  a  clause  is  mandatory 
or  discretionary. 


8.1  Mandatory  Clause 


8.1 .1  Subcontract  Silence 

The  strongest  argument  for  awarding  the  government  an  entitlement  to  the  same  rights  in 
subcontractor-produced  software  (or  technical  data)  as  it  had  arranged  for  with  the  prime  is  when 
the  subcontract  is  silent  as  to  the  issue  and  the  issue  pertains  to  something  addressed  in  a 
clause  that  is  mandatory  in  government  software  acquisition  contracts,  for  example,  the  standard 
data  rights  clause.  The  same  policy  considerations  that  prompted  the  court  in  G.L.  Christian  & 
Associates  v.  United  States  [29]  to  read  a  mandatory  “termination  at  the  convenience  of  the 
government"  clause  into  a  government  contract  would  seem  to  apply  as  to  subcontract  arrange¬ 
ments.  Subcontractors  will  surely  know  that  the  software  they  are  developing  is  being  developed 
for  the  government.  They  would  probably  be  held  to  have  constructive  notice  that  DoD  regula¬ 
tions  require  inclusion  of  the  standard  data  rights  clause  in  software  development  contracts  un¬ 
less  a  deviation  is  granted  ( [61]  sec.  27.404-2(b)(2))  and  that  the  standard  clause  requires 
primes  to  flow  government  requirements  down  ( [61]  sec.  52.227-7013(g)(l)).  Regulations  such 
as  these  have  the  force  and  effect  of  law  (Caha  v.  United  States  [22]).  From  a  policy  standpoint, 
the  effectiveness  of  the  regulations  in  creating  a  system  in  which  the  government  will  know  what 
rights  it  has  in  everything  it  buyi.  would  be  seriously  undermined  if  subcontractors  were  allowed  to 
avoid  mandatory  clause  flowdowns  without  making  a  special  showing  of  need  for  a  deviation. 
The  regulations  define,  in  many  respects,  what  minimum  rights  the  government  must  have.  Un¬ 
less  a  deviation  is  obtained,  the  government  would  seem  to  have  the  right  to  expect  that  this  set 
of  minimum  requirements  would  be  met. 


8.1 .2  Contradictory  Clauses 

Suppose  the  prime  is  unable  to  persuade  a  subcontractor  to  allow  the  government  to  modify  the 
software  and  agrees  to  inclusion  of  a  clause  that  precludes  modification.  Regardless  of  whether 
the  standard  data  rights  clause  is  included  or  excluded,  would  the  government  have  the  right  to 
modify  the  software?  The  issue  is  important  because  commercial  licensing  arrangements  typi¬ 
cally  do  not  allow  the  licensee  to  make  modifications  or  enhancements.  Subcontractors  for 
software  may  be  quite  insistent  that  the  software  not  be  modified,  especially  if  the  software  is  to 
be  warranted. 

As  Chapter  2  above  indicated,  some  contract  officers  seem  to  believe  the  government  would  not 
have  the  right  to  modify  software  if  the  prime  had  negotiated  the  right  away.  Other  government 
lawyers  to  whom  we  spoke  believed  that  the  government  would  still  have  the  right  to  modify  the 
software  notwithstanding  the  contrary  agreement.  One  lawyer  cited  Technical  Development 
Corp.  v.  United  States  [46]  in  support  of  this  theory.  Certainly,  the  policy  considerations  which 
support  the  Christian  doctrine  and  its  application  in  subcontractor  contexts  would  seem  to  be 
useful  to  the  government  when  confronted  with  a  clause  in  contradiction  to  the  government's 
standard  set  of  rights.  A  deviation  is  always  available  if  a  special  case  can  be  made  for  limiting 
the  government’s  rights  in  particular  instances.  In  the  absence  of  a  deviation,  the  government 
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would  seem  entitled  to  the  benefit  of  the  minimum  rights  guaranteed  under  the  standard  data 
rights  clause.  Contract  officers,  acting  outside  of  their  authority,  cannot  bind  the  government  [47], 


8.1.3  Partial  Contradiction 

Suppose  instead  that  a  software  producer  was  required  to  deliver  three  pieces  of  software  to  a 
prime  for  the  government  and  was  willing  to  let  two  of  the  pieces  of  software  be  modified,  but  not 
the  third.  Suppose  further  that  the  subcontractor  realized  that  the  standard  data  rights  clause 
was  incorporated  by  reference  in  the  subcontract  and  expected  and  intended  for  that  clause  to 
apply  as  to  the  two  pieces  of  software,  but  negotiated  with  the  prime  for  a  special  clause  preclud¬ 
ing  modification  of  the  third.  A  court  applying  general  contract  law  would  probably  try  to  interpret 
the  seemingly  conflicting  clauses  in  a  way  that  would  reconcile  the  conflict  (e.g.,  City  of  Columbia, 
Mo.  v.  Paul  N.  Howard  Co.  [27]).  One  way  to  reconcile  the  conflict  would  be  to  say  that  the 
standard  clause  applies  to  the  first  two  and  the  "no  modification"  clause  to  the  third.  General 
contract  law  might  also  tend  to  favor  subsequent  and  more  specific  expressions  of  the  parties' 
intent  when  construing  conflicting  clauses  (e.g.,  Matter  of  Antuna  [36]).  This  too  might  seem  to 
favor  giving  effect  to  the  "no  modification"  clause. 

On  the  other  hand,  when  one  is  talking  about  a  mandatory  clause,  that  is,  a  clause  that  is  re¬ 
quired  by  regulation  and  that  is  itself  a  regulation,  a  strong  argument  can  be  made  that  it  should 
apply  notwithstanding  the  arguments  that  favor  the  subcontractor.  Government  contract  law, 
after  all,  is  somewhat  different  from  general  contract  law. 

8.1 .4  Subcontract  Clause  Resolving  an  Ambiguity  in  the  Mandatory  Clause 

Suppose  that  a  subcontractor  agrees  to  develop  a  piece  of  software  at  public  expense.  Assume 
that  he  realizes  that  there  is  an  ambiguity  in  the  standard  data  rights  clause  as  to  the  extent  of  the 
government's  rights  in  such  software  -  unlimited  rights  or  a  license  for  governmental  purposes 
(See  Chapter  1)  --  and  decides  that  in  the  subcontract,  he  is  going  to  resolve  the  ambiguity  by 
putting  a  clause  in  the  contract  giving  himself  the  copyright,  giving  to  the  prime  a  license  to  use 
the  software  for  governmental  purposes  and  permission  to  sublicense  the  government  for  the 
same,  and  defining  "governmental  purposes"  to  exclude  "giveaways"  to  industry. 

The  subcontractor's  argument  for  enforcement  of  his  rights  as  against  the  government  is  much 
stronger  here  than  in  the  previous  hypotheticals.  Although  an  agency  is  ordinarily  entitled  to 
interpret  its  own  regulations,  courts  will  not  always  accept  later  developed  interpretations  of 
regulations  that  would  defeat  the  reasonable  expectations  of  those  who  have  produced  and 
delivered  a  product  in  reliance  on  a  particular,  reasonable  interpretation  of  the  regulations.  A 
potential  subcontractor  might  need  to  be  able  to  assess  the  extent  of  his  commercial  market  for 
the  software  to  decide  whether  and  on  what  terms  to  bid.  If  resolving  the  ambiguity  will  aid  in  his 
planning  and  will  encourage  him  to  bid,  why  not  allow  the  subcontractor  his  supplement?  After 
all,  the  government  had  ample  opportunity  to  define  its  rights  and  its  terms  in  advance  of  the 
subcontract,  and  failed  to  do  so. 
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8.2  Discretionary  or  Special  Clauses 

There  are  many  clauses  in  government  contracts  that  are  not  mandatory.  Some  are  standard 
discretionary  clauses,  such  as  the  special  works  clause  [61]  sec.  52.227*7020).  Some  are  spe¬ 
cially  drafted  for  particular  contracts,  for  example,  clauses  defining  the  scope  of  warranty  rights  in 
software.  If  a  prime  contractor  has  promised  the  government  to  obtain  certain  rights  under  a 
discretionary  clause  (e.g.,  to  obtain  a  copyright  for  the  government  or  to  obtain  strong  warranties), 
and  the  prime  is  either  unable  or  neglects  to  get  a  commitment  for  such  right  from  a  subcontrac¬ 
tor,  it  seems  unlikely  that  the  government  could  enforce  against  the  subcontractor  the  rights  it  had 
expected  the  prime  to  get  for  it.  We  were  told  of  a  number  of  examples  of  this  kind  of  problem. 
We  were  given  to  understand  that  these  situations  tended  to  be  resolved  through  negotiation,  the 
prime  typically  conceding  its  neglect  and  offering  some  penance,  but  without  the  subcontractor 
giving  in  further.  This  was  perceived  by  DoD  lawyers  to  be  a  serious  problem,  particularly  as  to 
software  licensing.  The  difficulty  for  a  contract  officer  in  finding  time  to  closely  supervise  data 
rights  provisions  in  subcontracts  was  often  cited  as  a  contributing  cause  of  this  problem.  Closer 
supervision  of  the  terms  of  subcontracts  would,  however,  seem  to  be  the  best  way  to  resolve  this 
set  of  problems. 


V  V  A 
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9.  Limitations  on  Governmental  Action:  Injunctions  and  Related 
Problems 


Most  software  intended  for  commercial  distribution  is  held  as  a  trade  secret  by  the  producer. 
Although  the  government  has  statutory  authority  to  infringe  patents  and  copyrights  ( [53]  sec. 
1498)  it  does  not  have  similar  authorization  to  appropriate  trade  secrets  against  the  owner's 
wishes.  Indeed,  there  is  a  criminal  statute  ( [69]  sec.  1905)  that  penalizes  any  federal  employee 
who  discloses  confidential  information  claimed  as  a  company's  trade  secret  without  authorization. 
Some  DoD  lawyers  are  worried  about  the  risk  in  litigation  with  a  software  producer  over  trade 
secret  software  of  an  injunction  issuing  against  governmental  use  of  the  software. 

This  is  a  risk  that  the  government  has  not  previously  had  to  confront  as  to  systems  acquired  from 
contractors  because  hardware,  if  protected  by  a  form  of  intellectual  property  law,  would  generally 
be  protected  only  by  patents,  which  the  government  could  infringe.  Trade  secrets  generally 
cannot  reside  in  hardware  since  reverse  engineering  of  the  hardware  would  readily  reveal  any 
such  ’secrets."  Because  software  is  now  often  protected  by  copyright  and  trade  secret  law,  a 
new  situation  has  arisen.  As  the  discussion  below  indicates,  there  is  good  reason  to  be  con¬ 
cerned  about  this  potential,  although  there  are  some  situations  (described  below)  in  which  the 
government  might  be  able  to  avoid  the  issuance  of  an  injunction. 

An  additional  basis  for  concern  about  injunctive  relief  has  been  expressed  because  of  a  series  of 
recent  federal  court  decisions  which  have  suggested  that  injunctive  relief  may  be  available  to 
prevent  the  government  from  releasing  material  in  which  it  claims  unlimited  rights  but  which  is 
claimed  as  a  trade  secret  by  its  producer.  This  danger  was  thought  by  several  DoD  lawyers  to  be 
particularly  acute  in  disputes  with  subcontractors  because  until  recently  there  has  been  no  formal 
procedure  under  the  Contracts  Dispute  Act  for  handling  controversies  about  data  rights  as  be¬ 
tween  a  subcontractor  and  the  government.  Some  thought  that  the  Contract  Disputes  Act  should 
be  amended  to  eliminate  this  risk.  One  provision  of  the  1985  DoD  Authorization  Act  may  partially 
address  this  problem. 

9.1  Limitations  of  28  U.S.C.  sac.  1498 

If  the  government  uses  or  manufactures  a  patented  invention  or  copies  or  distributes  a 
copyrighted  work  without  the  owner's  permission,  section  1498  of  Title  28  of  the  U.S.  Code  says 
that  the  exclusive  remedy  of  the  patentee  or  copyright  owner  is  an  action  for  damages  in  the 
Claims  Court .  This  statute  effectively  prevents  injunctive  relief  from  being  entered  against  the 
government  for  patent  or  copyright  infringements  (e.g.,  Pitcairn  v.  United  States  [41]).  One  of  the 
reasons  that  this  shield  from  injunctions  is  available  as  to  copyrights  and  patents,  but  not  trade 
secrets,  is  that  if  one  infringes  a  patent  or  copyright,  the  patent  or  copyright  will  survive  the 
infringement,  whereas  an  appropriation  of  the  trade  secret  can  utterly  destroy  the  trade  secret,  as 
for  example,  when  the  government  distributes  trade  secret  information  about  a  spare  part  for 
competitive  reprocurement  purposes.  An  injunction  is  the  only  thing  that  can  prevent  the  loss  of 
the  trade  secret.  Because  of  this,  it  seems  unlikely  Congress  would  amend  this  statute  to  grant 
the  government  broad  discretion  to  appropriate  trade  secrets. 
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9.1.1  Forcing  an  Election  of  Copyright 

Software  is  copyrightable  subject  matter  (Apple  Computer,  Inc.  v.  Franklin  Computer  Corp.  [19]). 
Because  software  is  copyrightable  and  because  copyright  protection  attaches  to  original  works  of 
authorship  from  the  time  of  their  creation  ( [59]  sec.  302(a)),  some  government  lawyers  have 
thought  that  the  government  would  be  able  to  use  section  1498  as  a  shield  against  an  injunction 
in  any  software  dispute. 

It  is  an  intriguing  theory,  but  there  are  some  problems  with  it.  There  does  not  seem  to  be  a 
precedent  that  would  support  the  theory  that  an  infringer  can  force  the  owner  of  an  unpublished 
work  to  opt  into  the  copyright  system  and  forego  trade  secret  protection  just  so  that  the  infringer 
can  avoid  an  injunction.  Indeed,  the  Supreme  Court  decision  in  Kewanee  Oil  Co.  v.  Bicron  Corp. 
[34]  indicates  that  a  company  has  the  right  to  choose  whether  to  rely  on  trade  secret  protection 
instead  of  seeking  a  patent.  Presumably,  the  Court  would  hold  similarly  as  to  copyrights. 

The  theory  would  also  seem  to  prove  too  much.  If  right,  it  would  mean  the  government  could 
release  any  or  all  technical  data  It  possessed,  regardless  of  Its  restrictive  legends,  because  vir¬ 
tually  all  of  the  things  that  qualify  as  "technical  data"  would  also  qualify  as  "original  works  of 
authorship"  under  the  copyright  law.  It  would  not  be  just  as  to  software  that  this  theory  would 
apply.  There  would  be,  then,  no  oompany  trade  secret  which  the  government  could  not  give 
away.  It  is  u  nlikely  that  courts  would  be  willing  to  permit  this  construction  of  the  reach  of  section 
1498. 

9.1 .2  Simultaneous  Copyright  and  Trade  Secret  Protection  In  Software 

The  present  standard  data  rights  clause  permits  developers  of  software  for  the  government  to 
retain  copyrights  in  the  software  ( [61]  sec.  52.227-7013(c)(1)).  For  reasons  discussed  in  Chap¬ 
ter  1 ,  there  may  be  an  incentive  for  a  software  producer  to  claim  a  copyright  in  the  software 
because  this  action  may  have  the  effect  of  cutting  back  on  the  extent  of  the  government's  rights, 
giving  them  a  license  to  the  software  for  governmental  purposes  rather  than  giving  them  unlimited 
rights.  Some  privately  developed  software  may  also  be  delivered  to  the  government  with 
copyright  notices. 

Some  government  lawyers  have  argued  that  whenever  software  is  delivered  with  any  indication  of 
an  intent  to  claim  copyright  protection,  that  means  that  section  1498  can  be  invoked  to  avoid  an 
injunction.  This  theory  is  more  plausible  than  the  previously  discussed  theory,  but  it  too  seems  to 
rely  on  an  election  of  protection  theory  that  may  not  hold  water.  That  is,  the  theory  boils  down  to 
the  idea  that  if  someone  claims  a  copyright  in  something,  he  cannot  claim  it  as  a  trade  secret  at 
the  same  time.  However,  simultaneous  copyright  and  trade  secret  protection  has  been  finding 
acceptance  in  the  courts  (see  e.g.,  Warrington  Assoc,  v.  Real  Ttme  Engineering  Systems,  Inc. 
[48])  in  which  the  court  held  that  even  if  computer  software  is  mass  marketed,  as  long  as  there  is 
an  agreement  not  to  disclose  by  the  purchaser,  trade  secrecy  as  well  as  copyright  protection  can 
be  maintained.)  And  many  software  producers  rely  on  both.  The  DoD  standard  data  rights 
clause  does  not,  either  explicitly  or  implicitly,  seem  to  require  any  election. 


On  the  other  hand,  DoD  FAR  SUPP  sec.  27.404-1(d)  [61]  does  say  that  "[pjatented  or 
copyrighted  computer  software  will  not  be  subject  to  any  agreement  prohibiting  the  government 
from  infringing  a  patent  or  copyright.*  The  likely  response  to  this  by  a  software  producer  who 
claims  simultaneous  oopyright  and  trade  secret  protection  in  software  is:  *!f  you  can  infringe  my 
copyright  without  violating  any  of  my  trade  secret  rights,  that's  OK;  I'll  take  my  claim  for  damages 
to  Claims  Court;  but  if  you  threaten  my  trade  secret  in  any  way,  I  will  sue  you  for  injunctive  relief." 

9.1.3  The  "Essence  of  the  Claim"  Test 

This  hypothetical  response  of  the  hypothetical  software  producer  suggests  a  refinement  of  the 
theory  discussed  in  the  previous  subsection  which  might  produce  a  shield  against  injunctions  in 
some  instances:  If  the  “essence*  of  the  claim  against  the  government  is  not  on  a  trade  secret, 
but  relates  to  an  infringement  of  the  copyright,  section  1498  may  shield  the  government  from 
injunctive  relief  despite  the  claim  of  simultaneous  copyright/trade  secret  protection.  For  example, 
if  some  Air  Force  officer  had  made  a  second  copy  of  some  software  to  give  to  one  of  his  co- 
workers,  the  ’essence*  of  the  owner's  claim  would  seem  to  be  damages  for  copying,  based  on  an 
infringement  of  the  copyright,  which  would  allow  the  government  to  invoke  section  1498.  If  in¬ 
stead  the  government  decided  to  give  out  a  company’s  trade  secret  source  code  to  the  defense 
contractor  community,  the  essence  of  the  owner's  claim  would  be  on  the  trade  secret,  and  thus 
injunctive  relief  might  be  awarded. 

9.1.4  NASA’s  Approach  to  Simultaneous  Protection 

If  a  firm  sells  NASA  rights  to  software  and  the  program  is  delivered  with  a  copyright  notice  and 
without  any  legend  saying  it  is  unpublished,  NASA  considers  the  software  to  be  published 
copyrighted  material  [64].  If  the  software  is  a  published  copyrighted  work,  then  the  ideas  it  con¬ 
tains  are  in  the  public  domain  and  can  no  longer  be  claimed  as  trade  secrets.  NASA  also 
considers  mass-marketed  software  as  published  software.  This  treatment  of  software  by  NASA  is 
an  important  way  to  claim  the  benefits  of  section  1498  by  eliminating  possble  trade  secret  claims 
and  forcing  copyright  infringement  claims  where  injunctions  are  not  permitted.  However,  this 
procedure  does  not  eliminate  the  threat  of  injunctions  if  the  company  delivers  the  software  with  a 
notice  that  it  is  unpublished.  DoD  might  want  to  consider  adopting  regulations  similar  to  NASA’s 
in  this  respect. 

9.1.5  National  Security  Grounds  for  Avoiding  Injunctive  Relief 

Several  of  the  government  lawyers  to  whom  we  spoke  about  this  issue  believed  that  the  govern¬ 
ment  would  never  be  enjoined  from  any  use,  duplication,  or  disclosure  of  software  because  even 
H  section  1498  did  not  preclude  an  injunction,  national  security  considerations  could  be  cited  to 
persuade  a  court  to  decline  issuing  an  injunction,  even  though  it  might  have  power  to  do  so.  It  is 
indeed  hard  to  imagine  a  court  ordering  the  F-16  fleet  grounded  because  some  software  producer 
has  a  dispute  over  his  rights  in  software  aboard  these  planes,  but  national  security  considerations 
may  not  always  win  the  day,  especially  where  the  software  is  being  used  by  the  government  in 
much  the  same  way  as  a  commercial  customer  might  use  it  (e  g.,  word  processing). 


9.1.6  Taking  Trade  Secret  Software  by  Eminent  Domain 

Trade  secrets  have  been  held  to  be  property  which  is  protected  by  the  Fifth  Amendment  of  the 
Constitution.  This  Amendment  prohfoits  the  government  from  taking  private  property  without  due 
process  of  law  or  without  just  compensation  (Ruckelshaus  v.  Monsanto  [44]).  It  appears  unlikely 
that  the  Defense  Department  can  exercise  the  power  of  eminent  domain  to  take  trade  secrets 
without  some  explicit  authorization  from  Congress  (see  e.g.,  United  States  v.  North  American  Co. 
[39],  indicating  the  need  for  Congressional  authorization  to  effect  a  valid  taking  under  the 
government’s  eminent  domain  powers). 

Section  1498  impliedly  authorizes  the  DoD  to  take  patents  and  copyrights  for  public  use  (Leesona 
Corp.  v.  U  S.  [35]).  The  court  in  that  case  declared  that  when  the  government  infringes  a  patent,  it 
has  'taken*  a  patent  license  under  an  eminent  domain  theory  based  on  the  implied  power  of 
Section  1498. 

It  is  not  clear  that  this  same  analysis  could  be  applied  to  a  taking  of  software  which  is  protected 
as  a  trade  secret.  There  does  not  appear  to  be  any  law  that,  either  expressly  or  impliedly,  would 
grant  the  government  broad  power  to  take  trade  secrets  whenever  the  DoD  feels  it  is  necessary. 
Although  regulations  which  are  promulgated  by  the  heads  of  departments  have  the  force  and 
effect  of  law  (Caha  v.  United  States  [22])  it  seems  doubtful  that  DoD  could  grant  itself  the  power 
to  'take"  trade  secrets.  From  the  present  interpretation  of  the  law,  this  power  probably  requires 
some  type  of  legislative  authority  from  Congress. 

9.1 .7  Liability  of  Government  Employees  for  Unauthorized  Disclosures  of  Trade 
Secrets 

If  a  government  employee  discloses  trade  secret  or  confidential  information  of  a  private  firm 
without  authorization,  that  employee  may  be  prosecuted  by  the  government  under  the  criminal 
provision  of  the  Trade  Secrets  Act  [69].  The  Trade  Secrets  Act  does  not  create  a  private  right  of 
action  which  would  allow  the  private  firm  to  sue  the  government  to  enjoin  any  disclosure  in  viola¬ 
tion  of  the  statute  (Chrysler  v.  Brown  [26])  but  the  statute  has  been  construed  to  provide  a  stan¬ 
dard  by  which  to  judge  the  legality  of  proposed  agency  disclosures.  One  court  has  construed  it  to 
create  a  federal  law  right  of  non-disciosure  (Chevron  Chemical  Co.  v.  Costle  [25]). 

9.1 .8  Injunctions  Against  Particular  Government  Employees 

Another  important  question  is  whether  a  government  employee  might  be  enjoined  against  use  of 
certain  software  in  the  course  of  his  employment,  even  if  the  government  itself  could  not  be 
enjoined.  An  example  was  given  of  a  lab  director  who  was  asked  to  sign  a  restrictive  license 
agreement  with  a  software  company.  This  license  agreement  was  not  made  part  of  the  contract 
which  was  signed  by  the  contracting  officer  and  did  not  oontain  the  minimum  rights  required  in 
software  contracts.  If  the  lab  director  had  violated  the  agreement,  the  company  could  not  sue  the 
government  because  the  lab  director,  who  was  not  a  contracting  officer,  had  no  authority  to  bind 
the  government  to  such  an  agreement  (see  e  g.,  Utah  Power  &  Light  Co.  v.  United  States 


[47]  where  the  Supreme  Court  ruled  that  the  United  States  is  not  bound  by  any  agreements 
entered  into  by  its  officers  which  are  not  permitted  by  law.)  It  is  possible  that  an  injunction  might 
issue  against  the  particular  lab  director’s  continued  use  of  the  software  in  a  way  that  violated  the 
agreement.  That,  of  course,  would  not  preclude  moving  the  employee  to  a  different  location  and 
having  the  software  used  by  a  new  lab  director  who  would  not  be  bound  by  the  agreement. 

9.2  Limitations  of  the  Contract  Disputes  and  Tucker  Acts  in  Disputes  Over 
Proprietary  Rights 

At  one  time,  the  government  could  argue  that  any  dispute  over  the  extent  of  its  data  rights  as  to 
any  piece  of  technical  data  or  software  deliverable  under  a  contract  was  a  dispute  under  the 
contract  that  could  be  shunted  into  the  Contract  Disputes  Act  or  Tucker  Act  frameworks.  This 
would  preclude  the  issuance  of  injunctive  relief  (e  g..  International  Engineering  Co.  v.  Richardson 
[32]).  Since  the  Supreme  Court  decision  in  (Chrysler  v.  Brown  [26]),  discussed  briefly  below,  a 
new  avenue  has  opened  up  for  litigating  data  rights  claims  against  the  government,  one  which 
seems  to  permit  injunctions  to  issue.  Contractors  concerned  about  the  government’s  impending 
release  of  proprietary  data  may  look  to  this  promising  new  avenue.  Government  lawyers  are 
rightly  concerned  about  this  development. 

9.2.1  The  Relevant  Cases 

It  was  the  Supreme  Court's  decision  in  Chrysler  v.  Brown  [26]  that  opened  up  this  new  door  to 
injunctive  relief  against  the  government  in  cases  involving  proprietary  data.  Chrysler  had  sued 
under  the  Administrative  Procedure  Act  for  an  injunction  to  prevent  the  Defense  Logistics  Agency 
from  releasing  data  about  Chrysler’s  affirmative  action  plan  to  persons  making  a  request  for  it 
under  the  Freedom  of  Information  Act.  The  Supreme  Court  held  that  DLA’s  decision  to  release 
the  data  was  "agency  action"  reviewabie  under  the  APA  by  a  person  who  had  suffered  a  legal 
wrong  or  had  been  adversely  affected  thereby  ( [54]  sec.  702).  The  APA  does  not  preclude 
injunctive  relief  against  the  government. 

Three  years  later,  in  Megapulse  v.  Lewis,  [37]  a  contractor  who  opposed  the  government's 
release  of  its  technical  data  for  competitive  reprocurement  purposes  sued  for  injunctive  relief 
under  Section  702  of  the  APA  in  reliance  on  Chrysler.  The  contractor  claimed  that  the  govern¬ 
ment  had  only  limited  rights  in  the  data;  the  government  claimed  unlimited  rights  in  it.  The  lower 
court  refused  to  issue  an  injunction  because  of  the  earlier  International  Engineering  decision. 
Megapulse  argued  to  the  Court  of  Appeals  that  Chrysler  v.  Brown  had  effectively  overruled  that 
earlier  case,  and  that  an  APA  action  was  now  available  when  an  agency  decided  to  release 
proprietary  data.  The  Court  of  Appeals  agreed  with  Megapulse  and  ruled  that  injunctive  relief 
was  possible.  The  court  stated  that  not  all  decisions  by  a  contract  officer  would  be  reviewabie 
under  the  APA.  Actions  against  the  government  that  were  in  essence  "contract"  claims  would  still 
have  to  be  pursued  under  the  Tucker  Act,  but  the  court  did  not  accept  the  government's  argument 
that  a  suit  over  proprietary  data  rights  was  essentially  a  contract  claim.  It  was  the  government, 
not  the  contractor,  who  was  relying  on  the  contract.  Although  the  Court  of  Appeals  did  not  order 
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an  injunction  to  issue,  it  directed  the  lower  court  to  "grant  such  non-monetary  relief  as  it  finds 
appropriate."  The  Meoaoulse  decision  has  many  government  lawyers  worried. 

The  Meoaoulse  decision  has  been  cited  approvingly  in  other  cases  including  B.K.  Instrument,  Inc. 
v.  United  States,  [21];  Williams  International  Corp.  v.  Lehman  ( [51];  and  Spectrum  Leasing  Corp. 
v.  United  States  [45].  Between  these  cases  the  Supreme  Court  decided  another  case  which 
some  DoD  lawyers  have  thought  to  be  somewhat  helpful  to  the  government’s  argument  that 
Meoaoulse  should  be  overruled.  That  case  is  Monsanto  Corp.  v.  Ruckelshaus  [44].  Monsanto 
complained  of  the  EPA’s  decision  (under  an  authorizing  statute)  to  release  valuable  information 
about  Monsanto's  pesticides  to  Monsanto’s  competitors.  Monsanto  argued  that  this  was  a  taking 
of  property  without  just  compensation  in  violation  of  the  Fifth  Amendment  to  the  Constitution.  As 
to  one  of  the  three  time  periods  involved,  the  Supreme  Court  found  that  there  may  have  been  a 
"taking"  of  the  trade  secret  through  a  decision  to  release  the  data,  which  would  require  just 
compensation  to  be  awarded  to  Monsanto.  However,  the  Supreme  Court  held  that  equitable 
relief  was  not  available  to  enjoin  the  taking  of  the  trade  secret  for  a  public  use  which  was  duly 
authorized  by  law;  a  Tucker  Act  claim  of  monetary  damages  would  be  the  only  remedy  available. 

The  Williams  International  case  discusses  the  implications  of  Monsanto  on  the  viability  of 
Megapulse.  Williams  International  involved  a  subcontractor  who  was  complaining  of  the  Navy's 
decision  to  remove  restrictive  legends  on  its  drawings  submitted  to  the  prime  contractor  who  in 
turn  submitted  them  to  the  Navy.  In  Williams  International,  the  government  relied  on  Monsanto 
for  the  proposition  that  injunctive  relief  was  unavailable  in  any  case  where  the  government  "took” 
a  trade  secret.  The  government  argued  that  Meoaoulse  had  implicitly  been  overruled  by  the 
Supreme  Court  in  Monsanto. .  The  court  in  Williams  International  disagreed.  Although  deciding  in 
favor  of  the  government  on  the  merits  of  the  controversy,  the  court  found  that  Meoaoulse  had  not 
been  overruled  by  Monsanto.  A  difference  the  court  found  significant  between  the  Meoaoulse 
and  Monsanto  situations  was  that  in  Monsanto  there  had  been  specific  legislative  authorization 
for  the  agency’s  release  of  data  such  as  Monsanto's.  Congress  therefore  had  intended  to  ex¬ 
ercise  its  eminent  domain  powers  if  necessary  to  achieve  the  release,  whereas  there  was  no 
similar  authorization  as  to  the  subcontractor's  data  in  Williams  International. 
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9.2.2  Application  to  Subcontractors  and  Primes 

Another  reason  the  court  in  Williams  International  decided  that  an  injunction  could  issue  against 
the  government  in  a  data  rights  dispute  of  that  sort  was  that  the  subcontractors  were  unable  to 
directly  bring  suit  against  the  government  under  the  Tucker  Act  or  make  use  of  the  Contract 
Disputes  Act  because  there  was  no  privity  of  contract  between  them  and  the  Navy.  The  ap¬ 
plicable  regulations  do  not  provide  a  mechanism  by  which  subcontractors  can  use  the  internal 
appeals  process  for  contract  disputes  with  primes.  [66]  44.203(c)  and  52.233-1 ,  Disputes.) 

The  DoD  Authorization  Act  of  1985(52]  may  provide  some  additional  buffer  against  injunctive 
relief  in  at  least  some  future  disputes  between  the  government  and  subcontractors  over 
proprietary  rights  in  material  delivered  under  contract.  Section  1216  of  that  Act,  now  embodied  in 
[57]  sec.  2321(e)  states; 
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If  a  claim  pertaining  to  the  validity  of  the  aaaerted  [proprietary]  restriction  is  submitted  in  writing 
to  a  contracting  officer  by  a  contractor  or  subcontractor  at  any  tier,  such  claim  shall  be  considered 
a  claim  within  the  meaning  of  the  Contract  Disputes  Act  of  1 978... 
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There  are  several  limitations  of  this  provision  which  merit  attention.  For  one  thing,  it  appears  that 
this  provision  will  apply  only  as  to  solicitations  issued  by  DoD  after  October  19, 1985,  and  thus 
will  not  affect  many  current  contracts.  Secondly,  when  one  looks  at  the  whole  of  section  2321  (of 
which  this  provision  is  a  part)  it  is  clear  that  by  its  terms  it  applies  only  to  technical  data,  and  not 
to  software.  Thirdly,  a  reading  of  the  whole  of  section  2321  raises  a  question  of  the  reach  of 
subsection  (e).  That  is,  it  would  appear  that  the  section  envisions  a  formal  challenge  procedure 
as  to  restrictive  legends  on  technical  data  when  contract  officers  and  contractors  (quite  notably,  it 
adds  subcontractors)  are  in  disagreement  when  the  material  is  delivered.  The  subsection  says  jf 
a  contractor  or  subcontractor  submits  a  claim  as  to  the  validity  of  the  restriction  within  this  formal 
challenge  mechanism,  that  claim  will  be  under  the  Contracts  Dispute  Act.  That  subsection  does 
not  say  that  all  claims  concerning  the  validity  of  restrictions  on  data  delivered  under  contract  are 
by  their  nature,  contract  claims  that  must  be  handled  exclusively  under  the  Contracts  Dispute  Act. 
If  instead  of  following  the  formal  challenge  procedure  under  section  2321 ,  the  government  simply 
decided  to  lift  the  restriction  for  competitive  reprocurement  (or  other)  purposes,  subsection  (e) 
might  not  provide  protection.  Thus,  while  this  provision  may  help  the  government  construct  an 
additional  defense  against  injunctions  in  some  instances,  it  does  not  appear  to  provide  a  com¬ 
plete  and  certain  shield  against  injunctions  in  all  software  rights  disputes. 

Similarly,  the  proposed  subpart  27.4  of  the  FAR  (66]  provides  at  sec.  52.227-24(i)  that  a  contract 
officer  may  deal  directly  with  a  subcontractor  at  any  tier  over  issues  related  to  restrictive  mark¬ 
ings.  This  provision  states  explicitly,  however,  that  it  neither  creates  nor  implies  privity  of  contract 
between  the  government  and  the  subcontractor.  This  provision  would  not  appear  to  help,  and 
may  even  work  against  any  efforts  by  the  government  to  bring  such  a  dispute  within  the  ambit  of 
the  Contract  Disputes  Act.  It  thus  appears  that  unless  the  Meoaoulse  and  Williams  International 
decisions  are  overruled,  DoD  wiU  still  have  to  worry  about  injunctions  issuing  in  software  disputes. 
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10.  Problems  Associated  with  CAD/CAM  Programs 


CAD/CAM  (computer  aided  design/computer  aided  manufacturing)  programs  are  likely  to  produce 
some  of  the  most  complex  and  hotly  contested  software  licensing  questions  for  DoD  over  the  next 
few  years.  The  current  acquisition  regulations  are  not  set  up  to  facilitate  acquisition  of  these 
important  tools.  This  Chapter  discusses  the  set  of  concerns  DoD  personnel  raised  about 
CAD/CAM  programs  in  the  course  of  our  interviews. 

10.1  What  CAD/CAM  Programs  Are  and  Why  They  Are  Important 

The  CAD  aspect  of  a  CAD/CAM  program  is,  as  the  name  implies,  a  tool  which  aids  in  the  design 
of  a  product.  The  CAD  provides  an  electronic  display,  a  blue  print  If  you  will,  on  which  to  make 
design  additions  and  alterations.  This  display  is  complete  with  measurements  and  specifications 
relevant  to  the  design  process.  The  CAM  aspect  of  a  CAD/CAM  allows  one  to  carry  this  process 
a  step  further.  With  the  CAM,  one  can  transmit  the  design,  through  telephone  lines  for  example, 
to  be  received  at  another  location.  More  importantly,  the  CAM  is  capable  of  causing  equipment  at 
the  remote  location  to  "tool  up*  and  begin  producing  the  item  which  has  been  designed  and 
transmitted.  Hence,  this  is  the  manufacturing  aspect  of  a  CAD/CAM  program.  A  CAD/CAM 
program  can  be  used  in  the  design  and  manufacture  of  components,  or  the  whole  of  a  product. 
Further,  CAD  programs  are  being  used  increasingly  often  in  the  development  of  software.  A 
CAD/CAM  program  can  thus  be  a  powerful  fool  in  the  development  and  growth  of  new  tech¬ 
nologies. 

There  are  various  CAD/CAM  programs  currently  available,  and  these  programs  are  not  neces¬ 
sarily  derivative  of  one  another.  In  order  to  access  and  modify  a  product  or  component  designed 
with  the  aid  of  a  CAD/CAM  program,  be  H  for  maintenance  or  enhancement  puiposes,  we  under¬ 
stand  that  one  must  use  the  very  same  CAD/CAM  program  that  was  originally  used  in  the  design 
and  manufacture  of  that  component  or  product.  It  seems  that  contractors  on  many  DoD  projects 
are  making  use  of  CAD/CAM  programs.  Our  understanding  is  that  different  CAD/CAM  programs 
are  being  used  in  those  projects.  Whether  or  how  much  they  may  be  derivative  of  one  another  is 
not  clear. 

CAP 'CAM  programs  have  significant  commercial  value  to  the  contractors  who  have  developed 
these  programs.  This  technology,  which  is  still  in  an  early  state  of  development,  promises  to 
have  a  major  impact  on  the  high  technology  field  as  it  is  further  developed  and  commercially 
exploited.  In  all  likelihood,  CAD/CAM  programs  will  be  among  the  most  commercially  lucrative  of 
technological  innovations  of  the  near  future.  Increased  use  of  such  programs  in  the  design  and 
manufacture  of  new  technology  seems  certain.  In  other  words,  CAD/CAM  programs  are  valuable 
commercial  items  that  can  be  expected  to  be  widely  used  in  large  scale  manufacturing  of  new 
technologies. 

Due  to  the  commercial  value  of  CAD/CAM  programs,  most  contractors  would  prefer  not  to 
provide  such  programs  -  that  is,  certainly  not  the  source  code  and  the  technical  documentation 


and  often  not  even  the  executable  code  --  to  the  government.  Contractors  seem  to  be  concerned 
that  providing  the  CAD/CAM  to  the  government  might  endanger  the  commercial  value  of  the 
program.  Our  information  is  that  some  of  these  contractors  may,  however,  be  willing  to  supply 
the  government  with  an  access  code  through  which  the  government  will  be  able  to  gain  remote 
access  to  the  firm's  CAD/CAM  system  for  a  particular  component  or  product  on  an  "as  needed" 
basis.  Further,  our  information  is  that  these  contractors  may  even  be  willing  to  allow  the  govern¬ 
ment  to  make  a  printout  of  a  particular  component  design  that  may  appear  on  the  terminal 
screen. 

Such  an  access  arrangement  would,  however,  raise  some  important  questions  and  concerns. 
The  primary  question  is  whether  such  limited  electronic  access  to  CAD/CAM  programs  used  in 
the  development  of  products  the  government  is  using  would  be  sufficient  to  meet  the  main¬ 
tenance  and  enhancement  needs  of  the  government  for  that  product. 


10.2  Access  to  the  Original  CAD/CAM  Program  Needed 

Because  of  the  substantial  commercial  value  of  such  programs,  contractors  are  constantly  chang¬ 
ing  —  improving  and  refining  —  the  CAD/CAM  programs  which  they  have  developed,  so  as  to 
make  those  programs  even  more  valuable.  The  life  cycle  of  components  used  by  DoD  is  very 
often  as  long  as  20  years.  Clearly,  software  industry  people  cannot  be  expected  to  keep  their 
CAD/CAM  programs  the  same  for  the  life  cycle  of  components.  Indeed,  our  understanding  is  that 
some  CAD/CAM  programs  are  changed  almost  daily. 

An  arrangement  allowing  access  to  a  CAD/CAM  program  for  maintenance/enhancement  would 
present  some  clear  dangers  for  the  government.  Under  such  an  arrangement,  it  would  be  the 
contractor  which  controlled  the  program,  and  it  would  be  the  contractor  which  would  be  in  a 
position  to  determine  whether  the  program  would  be  changed.  For  the  CAD/CAM  program  to  be 
adequate  for  the  government’s  maintenance  and  enhancement  needs,  the  government  would 
need  an  explicit  agreement  that  the  original  CAD/CAM  program  would  remain  available  to  it. 
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10.3  The  Need  for  Irrevocable  Access 

Another  critical  consideration  regarding  access  arrangements  for  DoD  would  be:  what  assurance 
will  the  government  have  that  its  access  to  the  CAD/CAM  would  not  be  cut  off?  For  example, 
what  happens  if  the  government  has  a  dispute  with  the  vendor  and,  in  retaliation,  the  vendor 
changes  the  access  code  to  the  CAD/CAM,  thereby  cutting  off  the  government's  access  to  the 
program.  The  control  of  access  to  the  CAD/CAM  program  remains  with  the  vendor  in  this  type  of 
accessing  arrangement.  The  government  would,  at  the  least,  want  to  get  a  contractual  agree¬ 
ment  from  the  vendor  that  access  to  the  CAD/CAM,  whether  through  change  of  the  access  code 
or  otherwise,  could  not  be  terminated.  Escrowing  the  CAD/CAM  program  with  a  neutral  third- 
party  might  be  another  way  to  protect  the  government's  interests. 
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10.4  Treatment  of  Electronic  Access  under  the  Regulations 

Electronic  access  to  CAD/CAM  is  in  some  ways  inferior  to,  or  at  least  different  than,  physical 
possession  of  the  program  and/or  technical  data.  Most  obviously,  access  to  technical  data  via  a 
CRT  provides  only  a  temporary  image  of  the  data— electronic  puises  on  a  screen.  This  raises 
various  difficult  questions.  How  would  such  access  be  handled  under  the  procurement  regula¬ 
tions:  as  software  or  as  technical  data?  The  CAD/CAM  program  would  clearly  be  software,  but 
without  delivery  it  cannot  be  classified  as  software  by  the  government  for  the  government  would 
not,  in  this  situation,  have  physically  received  the  actual  software.  An  electronic  image  does  not, 
on  the  other  hand,  seem  to  fit  the  definition  of  technical  data,  but  a  printout  of  the  image  and/or 
information  would  seem  to  fit  the  definition  of  technical  data  ( [61]  sec.  227.401,  regarding  the 
definition  of  technical  data:  'The  data  may  be  graphic  or  pictorial  delineations  in  media  such  as 
...  computer  printouts"). 

If  the  government  only  gets  access  to  CAD/CAM,  what  is  it  getting?  Should  electronic  access  be 
treated  as  software  or  as  technical  data?  How  should  printouts  of  the  electronic  image  be 
treated?  How  would  the  applicable  procurement  regulations  be  applied?  Are  the  FAR  and  FAR 
SUPP  flexible  enough  to  deal  with  a  new  situation  such  as  software  which  is  part  of  the  manufac¬ 
turing  process?  The  answers  to  these  questions  do  not  spring  readily  from  the  existing  regula¬ 
tions  and  DoD  policy  in  this  area. 

What  some  contractors  are  reportedly  offering  in  the  way  of  access  to  a  CAD/CAM  appears  to  be 
a  limited  license  for  maintenance  purposes;  it  is  clearly  less  than  restricted  rights.  Do  the  regula¬ 
tions  permit  the  government  to  enter  into  this  kind  of  arrangement?  It  is  not  clear  what  rights  the 
government  would  be  required  to  obtain  in  CAD/CAM  under  the  procurement  regulations,  nor  is  it 
clear  what  data  rights  attach  to  the  electronic  image  or  to  the  printout  of  CRT  images. 

An  arrangement  of  this  sort  might  have  an  adverse  impact  on  any  plans  DoD  has  with  regard  to 
competitive  reprocurement.  Government  personnel  are  concerned  about  whether  the  government 
would  have  the  right  to  show  another  contractor  the  printout  for  purposes  of  spare  parts  procure¬ 
ment  or  maintenance/enhancement  of  the  product  designed  with  the  aid  of  the  CAD/CAM 
program.  Some  have  also  wondered  about  the  effect  of  the  Maintenance  Clause  (Section  1  -202) 
of  the  DoD  Authorization  Act  which  seems  to  require  that  DoD  acquire  sufficient  rights  to  maintain 
software:  would  electronic  access  to  the  CAD/CAM  program  meet  the  mandate  of  this  legis¬ 
lation? 

Each  of  these  questions  would  require  further  study  before  policy  recommendations  regarding 
CAD/CAM  programs  would  be  possible.  Until  some  policy  regarding  CAD/CAM  programs  is 
developed,  it  seems  likely  that  government  personnel  will  be  in  a  quandary  as  to  how  to  react 
when  confronted  with  a  data  rights  question  involving  a  CAD/CAM. 


10.5  Ability  of  DoD  Personnel  to  Make  Use  of  Electronic  Access  Material 

Another  difficult  question  is  whether  the  government  can  effectively  make  use  of  on-screen  tech¬ 
nical  data  for  maintenance/enhancement  purposes.  Some  to  whom  we  have  spoken  have 
doubted  that  government  personnel  have  the  "know-how”  to  make  appropriate  use  of  CAD/CAM 
programs  and  technical  data  they  may  contain.  CAD/CAM  programs  tend  not  to  be  very  "user- 
friendly."  Not  being  able  to  find  material  they  need,  or  even  realizing  it  is  accessible  via  the 
electronic  access  to  the  CAD/CAM  creates  a  real-world  problem  for  government  personnel.  A 
contract  with  the  CAD/CAM  purveyor  to  supply  training  or  "know  how"  on  an  as  needed  basis 
might  answer  some  of  these  problems. 

We  understand  that  the  Air  Force  has  begun  to  encourage  the  delivery  of  technical  data  via 
electronic  media.  At  least  some  Air  Force  policy  makers  seem  to  feel  that  electronically  acces¬ 
sible  technical  data  is  preferable  to  data  delivered  in  more  traditional  paper  form.  Electronic  data 
allows  for  easier  storage,  and  over  time,  as  electronic  media  are  increasingly  used  for  such  data, 
it  will  hopefully  become  easier  for  personnel  to  use. 

10.6  Conclusion 

CAD/CAM  programs  are  a  valuable  technology  that  DoD  should  encourage,  even  if  industry  may 
only  be  willing  to  provide  access  to  the  CAD/CAM,  not  a  physical  copy.  As  long  as  the  govern¬ 
ment  has  assurances  that  its  access  to  the  original  CAD/CAM  program  will  not  be  cut  off, 
electronic  access  to  CAD/CAM  may  actually  provide  some  benefits  over  physical  delivery  of  tech¬ 
nical  data.  At  any  rate,  the  government  should  think  through  its  policy  in  this  area  and  determine 
what  type  of  arrangement,  consistent  with  regulatory  requirements,  will  protect  its  interests  in 
access  to  CAD/CAM. 


11.  Problems  Arising  from  Software's  Hybrid  Nature:  of  Warranties 
and  Other  Matters 

Software  in  its  machine-readable  form  has  some  characteristics  of  hardware  and  some  charac¬ 
teristics  of  technical  data.  This  hybrid  character  of  software  has  led  to  some  confusion  within  the 
Department  of  Defense  about  the  manner  in  which  software  should  be  acquired  and  maintained 
after  acquisition:  should  it  be  treated  like  hardware,  or  like  technical  data,  or  differently  from 
both?  The  hybrid  character  of  software  also  has  a  bearing  on  other  questions,  such  as  whether 
implied  warranties  may  attach  to  it. 


11.1  The  Hybrid  Character  of  Software 

11.1.1  Hardware  and  Software 

Software  is  like  hardware  in  that  it  causes  machines  to  do  things.  Software  is  in  fact  merely  a 
replacement  for  hardware  components  that  could  otherwise  perform  the  same  function.  Software 
is  embedded  in  hardware  and  part  of  an  overall  hardware  system.  Like  hardware,  software  can 
often  serve  as  a  tool  for  creating  other  items.  Like  hardware,  software  needs  maintenance  work 
from  time  to  time  to  operate  properly. 

Software  is  unlike  hardware,  however,  in  a  great  many  ways.  Software  is,  for  example,  easy  and 
cheap  to  replicate  as  compared  with  hardware.  Once  the  first  copy  has  been  produced,  software 
can  be  almost  endlessly  replicated  at  almost  no  cost  regardless  of  how  complex  the  code  is.  One 
of  the  consequences  of  this  is  that  the  government  tends  to  think  that  additional  copies  of 
software  ought  to  be  deliverable  at  a  very  low  cost,  whereas  industry,  which  is  concerned  about 
recouping  its  research  and  development  costs  and  about  “piracy’  of  its  product  which  the  firm 
may  be  helpless  to  prevent,  and  which  regards  the  sale  of  software  as  the  sale  of  a  production 
facility  (as  if  one  bought  a  General  Motors  factory  when  one  bought  a  truck  produced  by  GM), 
regards  additional  sales  at  higher  price  levels  to  be  necessary  to  make  the  software  business 
viable.  A  second  consequence  of  this  low-cost  replicability  is  that  the  software  industry,  for  the 
most  part,  tends  to  make  its  products  available  only  on  a  highly  restrictive  licensing  basis,  rather 
than  selling  copies  outright. 

Another  important  difference  between  software  and  hardware  is  that  software  may  be  wholly 
subject  to  a  lengthy  lawful  monopoly  (i.e.,  a  copyright)  as  well  as  being  held  as  a  trade  secret, 
whereas  hardware  may  be  subject  to  a  much  shorter  monopoly  (i.e.,  a  patent)  and  most  often 
cannot  be  held  as  a  trade  secret  since  it  generally  can  be  reverse  engineered.  Moreover,  quite 
often  hardware  is  either  not  patented  at  all  or  only  subject  to  partial  patent  protection.  A  high 
standard  of  inventiveness  is  required  for  patent,  while  copyright  requires  only  the  most  minimal 
originality.  Hardware,  unlike  software,  cannot  be  copyrighted  at  all.  The  bottom  line  of  all  of  this 
is  that  it  will  be  much  harder  to  get  competition  as  to  software  reprocurements  and  maintenance 
than  as  to  hardware  because  of  the  stronger  intellectual  property  protection  afforded  to  the  whole 
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of  a  piece  of  software  (e  g.,  control  over  making  derivative  work)  as  compared  with  the  whole  of  a 
piece  of  hardware  This  means  that  it  is  even  easier  to  get  into  a  "sole  source"  arrangement  as  to 
software  than  as  to  hardware.  Because  the  government  is  becoming  ever  more  dependent  on 
software,  this  has  to  be  a  serious  concern 

Moreover,  because  software  engineering  is  still  in  early  stages  of  development,  it  is  generally 
more  difficult  to  specfy  how  software  (as  compared  with  hardware)  should  be  developed  for 
particular  functions  ano  to  estimate  the  costs  and  development  schedule  for  it.  Software  is  also 
virtually  "invisible"  as  compared  with  hardware,  which  means  that  it  is  more  difficult  to  detect  if 
someone  delivers  very  similar  or  nearly  identical  software  on  a  second  development  contract. 
And  "invisibility"  means  that  it  may  be  more  difficult,  as  a  general  matter,  to  detect  defects  in 
software  or  to  know  how  to  fix  them  once  the  defect  is  known.  Again,  because  software  en¬ 
gineering  is  a  developing  art,  software  is  likely  to  contain  a  lot  of  undetected  defects  that  will  need 
to  be  corrected  while  in  the  user's  possession.  Unlike  hardware,  software  is  readily  changeable; 
new  capabilities  can  be  added  without  substantial  additional  plant  or  material  costs.  All  it  takes  is 
labor  Ail  of  this  tends  to  make  software  maintenance  and  enhancement  a  much  bigger  part  of 
software  life  cycle  planning  than  is  the  case  with  hardware. 


1 1 .1 .2  Software  and  Technical  Data 

Software  and  technical  data  are  similar  in  being  recorded  information.  They  are  also  alike  in  that 
both  are  often  held  as  trade  secrets  and  licensed  under  restrictive  conditions,  rather  than  being 
sold  in  the  marketplace.  Loss  of  the  secrets  may  undermine  or  destroy  the  firm's  commercial 
advantage.  Both  are  also  capable  of  being  claimed  as  unpublished  copyright  material.  Both 
involve  modest  production  costs  in  themselves  once  the  technology  they  embody  has  been 
developed.  Both  are  difficult  to  price  with  any  precision.  Because  the  material  costs  are  low  (i.e, 
what  it  costs  to  do  a  drawing  on  paper,  what  it  costs  to  make  a  second  copy  of  software),  the 
government  often  thinks  the  price  ought  to  be  low.  Because  it  is  the  valuable  technology  that 
they  embody  that  the  firm  wants  to  protect  and  exploit,  industry  tends  to  price  them  high.  With 
both,  sometimes  crucial  information  necessary  for  maintenance  or  enhancement  of  the  item  to 
which  they  pertain  may  not  be  readily  apparent  from  examination  of  the  paper  or  disk;  rather  it 
may  be  stored  away  in  the  memory  of  some  engineer  who  designed  It.  Ongoing  service  contracts 
are  sometimes  necessary  to  be  able  to  gain  access  to  that  expertise. 

Where  software  differs  from  technical  data  is  in  being  an  "end  item"  in  itself.  Software  is  a 
product  that  will  perform  machine  functions,  whereas  technical  data  is  merely  information  about  a 
product.  As  an  end  item,  software  will  more  likely  be  a  product  with  a  commercial  market 
whereas  technical  data  will  often  not  be  sold  or  licensed  to  anyone  but  the  government.  When 
altered,  software  will  perform  differently,  as  compared  with  technical  data  which  will  simply  reflect 
a  new  configuration.  Software  also  requires  an  environment  of  equipment  and  other  software  to 
be  effective. 


V, 


112 


r»;  >?:%  rot  «  r-vv.  ivy  w  cvv  y-i 


1 1 .1 .3  The  Implications  of  Software’s  Hybrid  Nature 

We  wish  that  we  could  provide  clear  guidance  as  to  the  acquisition  and  maintenance  implications 
of  the  differences  between  software  and  hardware  and  between  software  and  technical  data. 
Many  persons  in  DoD  whom  we  interviewed  were  deeply  puzzled  about  this  subject  and  regarded 
solving  this  puzzle  as  crucial  to  making  better  decisions  about  DoD’s  software  acquisition 
policies.  The  discussion  of  the  two  previous  subsections  reflects  the  factors  that  fueled  the 
puzzlement  of  those  to  whom  we  spoke.  It  does  seem  that  software  is  sufficiently  different  from 
hardware  and  technical  data  that  software  cannot  be  acquired  or  managed  as  if  it  was  hardware, 
or  as  if  it  was  simply  technical  data. 

11.2  Implied  Warranties  for  Software 

Although  there  are  a  great  many  questions  which  the  hybrid  nature  of  software  raises,  we  will 
only  dwell  on  one  that  was  frequently  raised  in  the  interviews  we  had  with  DoD  personnel: 
whether,  in  the  absence  of  any  contractual  provision  as  to  warranties,  there  might  be  any  implied 
warranties  -  of  merchantability  or  of  fitness  for  a  particular  purpose  --  that  might  attach  to 
software  delivered  to  the  government.  The  reason  this  is  a  "hybrid  nature’  question  is  that  the 
answer  to  the  question  seems  to  turn  largely  on  whether  software  is  more  properly  characterized 
as  a  "good"  or  as  a  "service".  Implied  warranties  do  not  attach  to  services;  they  may  apply  to 
goods. 

Hardware  --  computers,  airplanes  and  hammers  --  is  clearly  "goods".  Technical  data  is  clearly 
not  "goods,"  but  may  be  reflective  of  a  service.  Preparing  software  is  a  service.  Maintaining 
software  is  a  service.  But  how  is  software  to  be  characterized  when  produced? 

Although  there  is  no  definitive  answer  to  this  question,  the  modem  trend  seems  to  be  to  treat 
software  as  a  "good"  (e.g.,  Carl  Beasly  Ford,  Inc.  v.  Burroughs  Corp.  [23],  and  [2]).  This  makes 
sense  given  that  software  performs  machine-lfce  functions  just  as  hardware  does.  The  fact  that 
software  manufacturers  so  often  disclaim  all  implied  warranties  might  indicate  their  acceptance  of 
a  strong  likelihood  that  software  products  will  be  treated  as  "goods”  for  warranty  purposes. 

A  second  hurdle  that  must  be  overcome  to  impose  implied  warranty  liability  on  a  software 
manufacturer  is  establishing  that  the  transaction  is  of  a  sort  that  qualifies.  Outright  sales  of  goods 
are  clearly  transactions  that  will  give  rise  to  implied  warranty  responsibilities;  leases  and  licenses 
are  less  clearly  covered.  Since  much  software  is  currently  licensed  rather  than  sold,  this  might 
seem  to  cut  against  the  argument  for  implying  warranty  protection.  However,  it  is  becoming  more 
common  to  apply  U.C.C.  [71]  principles  to  lease  and  licensing  transactions  (e  g.,  Chatlos  Sys¬ 
tems,  Inc.  v.  National  Cash  Register  Corp.  [24]  and  Westmont  Tractor  Co.  v.  Viking  Exploration, 
Inc.,  [49]).  So  this  too  may  be  a  surmountable  obstacle. 

Thirdly,  there  is  a  question  of  whether  implied  warranties  may  attach  to  software  sold  to  the 
government.  Sales  to  the  government  are  governed  by  federal  contract  law,  not  state  contract 
law,  such  as  the  Uniform  Commercial  Code  [71],  It  appears  that  when  there  are  no  specific 


federal  laws  which  contradict  the  provisions  of  the  U.C.C.,  courts  have  increasingly  applied 
U.C.C.  principles  as  a  statement  of  the  modem  law  of  contracts  to  be  used  in  federal  contract 
cases  as  well  (United  States  v.  Conrad  Publishing  Co.  [28)).  Implied  warranty  liability  under 
U.C.C.  principles  has  been  imposed  in  prior  government  contract  cases  (see  e.g.,  Appeals  of 
Reeves  Soundcraft  Corp.  (18)  in  which  the  Armed  Services  Board  of  Contract  Appeals  upheld  the 
government’s  right  to  refuse  to  accept  a  delivery  of  magnetic  tape  claiming  the  tape  did  not  meet 
the  standards  set  by  the  parties  to  the  contract.  An  implied  warranty  was  found,  applying  prin¬ 
ciples  of  the  U.C.C.  and  the  Uniform  Sales  Act  as  guides  to  federal  law  in  the  area  of  implied 
warranties).  It  would  surely  not  seem  reasonable  that  the  government  be  accorded  less  warranty 
protection  than  any  other  commercial  customers  of  a  seller.  Under  the  U.C.C.,  implied  warranties 
of  merchantability  automatically  arise  in  every  transaction  involving  a  merchant-seller  ( [71]  sec. 
2-314)  (unless  appropriately  disclaimed)  and  an  implied  warranty  of  fitness  for  a  particular  pur¬ 
pose  will  be  enforceable  if  the  seller  has  reason  to  know  of  the  buyer's  particular  purpose  for  the 
software  and  that  the  buyer  is  relying  on  the  seller's  expertise  in  choosing  or  designing  the  correct 
software  (see  [71)  sec.  2-315).  Therefore,  if  the  software  doesn’t  perform  correctly  and  there  is 
not  an  explicit  disclaimer  of  implied  warranty  protection,  there  would  seem  to  be  some  basis  for  a 
government  claim  of  implied  warranties  as  to  software  delivered  to  it.  although  in  many  cases 
there  may  be  a  disclaimer. 

And  finally,  software  can  be  reused.  The  reuse  of  software  further  complicates  the  warranty 
situation  in  that  the  reused  modules  will  often  be  subject  to  separate  and  distinct  warranty  provi¬ 
sions  in  themselves.  The  effect  of  the  reuse  on  the  warranty  which  applies  to  the  module,  and 
the  effect  of  the  reuse  on  the  ultimate  product  are  difficult  questions  which  add  to  the  lack  of 
clarity  as  to  this  issue. 


12.  Problems  Arising  from  New  Chip  Protection  Law 


Congress  recently  passed  the  Semiconductor  Chip  Protection  Act  of  1984  [67]  which  created  a 
new  form  of  intellectual  property  law  to  protect  semiconductor  chip  designs.  This  law  resembles 
patent  law  in  certain  ways  and  copyright  law  in  certain  ways.  It  also  contains  some  new  and 
unique  features  which  are  found  in  neither  copyright  nor  patent  law.  The  federal  procurement 
regulations  have  not  yet  been  amended  to  take  this  new  law  into  account.  Because  much 
software  that  the  government  buys  is  delivered  on  semiconductors  and  because  chips  are  so 
intimately  related  to  computer  systems  acquisitions  of  which  software  is  a  part,  several  DoD 
persons  were  concerned  about  how  this  new  law  should  be  treated  under  the  FAR  or  DoD  FAR 
SUPP. 

Because  ignorance  of  what  the  law  provides  and  having  no  policy  about  the  law  means  that  the 
DoD  may  be  more  likely  to  get  into  trouble  over  the  issue,  it  would  seem  worthwhile  to  understand 
the  law  and  make  a  policy  about  it. 

12.1  An  Overview  of  the  Semiconductor  Chip  Protection  Act 

Under  the  chip  protection  law  [67],  persons  who  create  'original*  mask  works  for  semiconductor 
chips  have  been  given  the  exclusive  right  to  control  the  creation  of  chips  embodying  that  design, 
as  well  as  the  importation  and  distribution  of  chips  embodying  that  design.  (The  standard  of 
originality  is  said  in  the  legislative  history  to  be  of  the  same  minimal  sort  as  is  true  in  copyright ) 
To  obtain  ten  years  of  protection  for  this  design,  the  mask  work’s  owner  must  apply  to  the 
Copyright  Office  for  a  certificate  of  registration  within  two  years  of  the  first  commercial  exploitation 
of  the  chip  design.  Chips  embodying  a  protected  design  may  (but  need  not)  display  a  symbol  of 
this  protection  (an  *M”  and  the  name  of  the  owner).  The  same  set  of  remedies  have  been 
provided  to  mask  work  owners  as  to  copyright  owners.  A  right  to  reverse  engineer  chip  designs 
is  specifically  provided  in  the  Chip  Protection  Act. 

The  legislative  history  of  the  chip  protection  law  makes  clear  that  any  programs  that  are  em¬ 
bedded  on  a  ROM  do  not  fall  within  the  scope  of  this  law.  Such  programs  may,  of  course,  be 
protected  under  the  copyright  law,  and/or  possibly  be  maintained  as  a  trade  secret.  The  chip 
protection  law  governs  only  as  to  the  design  of  the  circuitry,  not  the  information  stored  on  it.  That 
is,  it  is  the  non-program  aspects  which  are  protected  under  the  chip  law. 


12.2  Circumstances  In  Which  It  Might  Matter  to  DoD  What  the  Chip  Law 
Provides 


12.2.1  Government  Funded  Development  of  Mask  Works/Chip  Designs 

We  have  not  spoken  with  anyone  in  the  Defense  Department  who  is  directly  involved  in  govern¬ 
ment  funding  of  chip  designs.  We  are  aware  of  the  VHSICs  program  and  we  have  reason  to 
believe  that  some  government  funding  of  chip  designs  is  ongoing.  Because  of  this,  some  formal 
DoD  policy  on  ownership  and  the  extent  of  rights  in  chip  designs  would  seem  to  be  appropriate. 

12.2.2  How  DoD  Might  Obtain  Ownership  of  the  Mask  Work 

Like  the  copyright  law,  there  is  a  provision  in  the  chip  law  that  mask  works  created  by  the  United 
States  government  can  not  be  protected  under  the  chip  law.  Again  like  the  copyright  law,  the  chip 
law  provides  that  the  United  States  government  is  not  precluded  from  receiving  or  holding  ex¬ 
clusive  rights  to  mask  works  by  assignment,  bequest  or  the  like.  Because  of  the  similarity  in  the 
wording  of  the  copyright  and  chip  law  provisions,  it  would  seem  to  make  sense  for  the  govern¬ 
ment  to  require,  if  it  wanted  to  own  the  chip  design,  the  developing  firm  to  get  a  mask  work 
certificate  and  to  assign  it  to  the  government  rather  than  to  try  to  use  an  approach  similar  to  that 
reflected  in  the  DoD  special  works  clause.  (See  Chapter  5.) 

12.2.3  How  DoD  Might  Obtain  Other  Rights  to  the  Mask  Work 

If  the  government  wants  to  allow  the  chip  designer  whose  work  it  might  be  funding  to  retain 
ownership  of  the  mask  work  and  wants  to  obtain  unlimited  rights  or  other  license  rights  to  use. 
disclose  or  duplicate  the  chip  design,  the  DoD  FAR  SUPP  would  have  to  be  amended.  The 
standard  data  rights  clause  presently  in  place  refers  only  to  technical  data  and  software.  The 
government  may  also  want  to  give  itself  the  right  to  distribute  the  protected  chips,  H  the  definition 
of  unlimited  rights  is  not  certain  to  include  it. 

Chip  designs  are  not  typically  held  as  trade  secrets  once  the  chip  has  been  sold  into  the 
marketplace  because  'publication*  of  the  chip  prevents  the  design  from  being  held  as  a  trade 
secret.  This  makes  the  proprietary  rights  provisions  of  the  standard  data  rights  clause  in¬ 
appropriate  for  use  in  a  contract  involving  acquiring  rights  in  chip  designs.  Technical  data  about 
the  process  of  manufacturing  the  chips  however,  might  still  present  the  same  acquisition  con¬ 
cerns  as  are  associated  with  other  technical  data. 

12.2.4  Government  Purchase  of  Infringing  Chips 
(a)  Purchase  for  Government  Use  Only 

Persons  (including  the  government)  who  buy  "pirate*  chips  or  who  buy  equipment  which  contains 
'pirate*  chips  for  their  own  use  will  not  be  liable  under  the  chip  law  to  the  person  who  owns  the 
mask  right  in  the  chips.  This  means  that  in  the  ordinary  case  where  the  government  might  buy 
equipment  for  its  use  (and  its  use  alone)  the  government  will  not  be  liable  to  the  chip  manufac¬ 
turer  if  one  of  its  contractors  has  used  "pirate*  chips  in  performance  of  a  contract  to  develop  the 
equipment.  It  is  irrelevant  whether  or  not  the  government  knows  that  the  contractor  was  using 


infringing  chips.  The  only  time  the  government  could  get  into  trouble  by  purchasing  equipment 
with  infringing  chips  for  use  by  government  employees  would  be  if  the  government  had  induced 
or  knowingly  caused  its  contractor  to  violate  one  of  the  exclusive  rights  of  the  mask  work  owner. 

(b)  Purchase  for  Redistribution 

If  the  government  buys  "pirate*  chips  or  equipment  containing  "pirate"  chips  and  the  government 
intends  to  distribute  these  items  to  another  entity  (such  as  to  GFE  it  or  to  make  a  foreign  military 
sale)  and  the  government  did  not  know  that  infringing  chips  were  used,  it  will  incur  no  liability  until 
it  learns  that  infringing  chips  were  used.  After  receiving  notice,  the  government  would  have  to 
pay  the  mask  work  owner  a  reasonable  royalty  on  any  chips  it  distributed  (i.e.,  sold,  leased, 
licensed,  exchanged,  etc.)  thereafter.  What  a  reasonable  royalty  is  may  be  decided  by  the 
parties  or  in  litigation.  A  failure  to  negotiate  about  the  reasonable  royalty  will  subject  the  formerly 
innocent  user  to  the  full  range  of  remedies  available  against  outright  infringers. 

Because  there  may  well  be  occasions  in  which  the  government  will  want  to  distribute  chips  or 
equipment  with  chips  in  it,  perhaps  the  government  should  revise  DoD  FAR  SUP P  to  require  the 
contractor  to  warrant  that  no  infringing  chips  were  used  and  to  indemnify  the  government  for  any 
liability. 

It  is  probably  worth  emphasizing  as  a  separate  matter  that  a  copyright  in  a  piece  of  software  is 
not  affected  in  any  way  by  the  chip  law. 

12.2.5  Manufacture  of  Chips 

Before  the  government  started  to  manufacture  chips  which  contained  a  protected  chip  design, 
authorization  from  the  owner  of  the  chip  mask  would  be  needed.  Manufacture  without  such 
authorization  would  be  an  infringement  of  the  proprietary  rights  of  the  owner  of  the  mask. 

12.2.6  Possibility  of  an  Injunction 

If  the  government  violated  the  rights  of  the  chip  mask  owner  through  manufacture  of  a  chip 
without  authorization  or  in  some  other  way,  and  the  owner  of  the  mask  sued,  28  U.S.C.  Sec.  1498 
[53]  would  not  protect  the  government  against  the  issuance  of  an  injunction  to  stop  the  use  of  the 
mask.  Sec.  1498  only  eliminates  the  possibility  of  an  injunction  against  the  government  tor  patent 
or  copyright  infringement  (see  Chapter  9)  and  has  not  been  extended  to  apply  to  infringements  of 
a  chip  mask. 


13.  A  Proposed  Approach  to  Solving  DoD’s  Software  Licensing 
Problems 

Having  raised  so  many  software  licensing  problems  in  the  course  of  this  report,  we  feel  some 
responsibility  to  suggest  at  least  an  approach  that  DoD  might  employ  to  solving  the  myriad 
problems  it  has  with  the  acquisition  and  maintenance  of  software.  Unfortunately,  there  is  no 
quick  and  easy  way  to  solve  aH  of  DoD’s  software  licensing  problems.  There  are  too  many 
different  types  of  problems,  stemming  from  too  many  different  causes.  There  is  also  too  much 
money  at  stake  for  any  "quick  fix"  solution  to  work.  The  situation  is  made  more  difficult  by  the 
strained  relationship  which  currently  exists  between  industry  and  government  with  regard  to 
software/data  rights  issues. 

That  does  not  mean,  however,  that  none  of  DoD’s  software  licensing  problems  can  be  resolved 
quickly  or  easily;  nor  does  it  mean  that  most  of  of  its  problems  are  u resolvable.  Removing  the 
inconsistencies  from  the  existing  procurement  regulations  described  in  Chapter  1  would,  for  ex¬ 
ample,  require  no  more  than  some  minor  alterations  to  those  regulations.  Improved  personnel 
policies  and  training  programs  could  alleviate  other  difficulties  DoD  is  experiencing.  And,  al¬ 
though  some  other  of  DoD’s  software  licensing  problems  may  be  more  resistant  to  solution  than 
others,  there  may  well  be  ways  of  approaching  even  the  major  problems  that  would  be  more 
constructive  than  other  approaches  which  might  be  taken. 

The  crucial  point  is  that  not  all  of  DoD's  software  licensing  problems  can,  or  should  be  treated  in 
the  same  way.  There  are  certain  problems  which  DoD  has  more  control  over  than  it  does  others. 
In  allocating  resources,  we  would  suggest  that  DoD  place  a  greater  emphasis  on  those  problems 
which  are  more  readily  within  its  control,  and,  therefore,  could  be  more  easily  resolved.  There  are 
also  some  software  licensing  problems  that  are  by  their  nature  more  amenable  to  change  than 
others.  Again,  in  allocating  the  time  and  resources  of  DoD  personnel  to  addressing  software 
licensing  problems,  we  would  advise  that  DoD  attempt  to  focus  its  limited  resources  on  those 
problems  which  are  most  fikety  to  be  impacted  by  such  an  effort. 

13.1  What  DoD  Has  Most  Control  Over 

13.1.1  How  DoD  Treats  Its  Personnel 

How  DoD  trains,  works,  and  rewards  its  contracting  personnel  is  an  important  factor  bearing  on 
its  software  licensing  problems  and  also  a  factor  over  which  DoD  has  considerable  control.  As 
Chapter  3  has  indicated,  the  DoD  contracting  personnel  to  whom  we  spoke  feel  they  could  benefit 
from  additional  training  about  software,  its  life  cycle  management,  and  data  rights.  Probably  the 
biggest  "return"  per  dollar  spent  on  solutions  could  be  obtained  by  improving  initial  training  about 
these  matters,  and  by  having  periodic  update  training. 


Once  on  the  job  and  trained,  procurement  personnel  should  also  have  manageable  workloads, 


accessible  and  knowledgeable  supervisors,  and  they  should  be  paid  reasonably.  In  other  words, 
they  should  be  accorded  working  conditions  that  are  not  seriously  disproportionate  to  those  of 
their  counterparts  in  private  industry.  Good  procurement  regulations  donl  heir  unless  you  have 
experienced,  well-trained,  and  dedicated  people  performing  the  acquisition  work.  Good  people 
can  work  around  problems  with  the  procurement  regulations.  If,  on  the  other  hand,  DoD  con¬ 
tinues  to  lose  its  best  people  to  industry  due  to  low  employee  morale,  inadequate  job  preparation, 
undesirable  working  conditions,  low  pay  and  so  on,  then  it  will  probably  also  continue  to  fare 
badly  in  its  dealings  with  industry  in  the  area  of  software/data  rights  procurement. 

13.1.2  Encouraging  Employees  to  Specialize  in  the  Software/Data  Rights  Area 

As  has  been  illustrated  throughout  this  report,  the  acquisition  of  software,  data  rights  and  other 
computer  related  technology  is  one  of  the  more  complex  and  specialized  areas  with  which  DoD 
personnel  become  involved  (see  Chapter  3).  Consequently,  it  would  be  beneficial  to  DoD  to  have 
some  personnel  who  are  sufficiently  specialized  in  this  area  that  they  would  be  adept  with  the 
intricacies  and  subtle  nuances  of  software  technology.  It  is  also  difficult,  if  not  impossible,  for  a 
legal  generalist  to  acquire  sufficient  knowledge  of  intellectual  property  and  software/data  rights 
issues  to  be  able  to  perform  well  in  negotiations  or  legal  conflicts  with  industry  people,  many  of 
whom  are  specialized  in  those  particular  areas.  In  particular,  DoD  would  probably  benefit  sig¬ 
nificantly  if  it  encouraged  more  of  its  attorneys  to  specialize  in  the  intellectual  property  area,  with 
some  of  these  focusing  their  efforts  on  software/data  rights  issues. 

13.1.3  Internal  Communications 

The  DoD  might  also  do  well  to  devote  more  of  its  resources  to  finding  strategies  which  would 
improve  internal  communications  within  DoD,  and  within  and  among  the  services  and  defense 
related  industries.  Better  feedback  mechanisms,  whereby  individuals  are  informed  not  only  of 
problems  which  arise  in  the  course  of  software/data  rights  acquisition,  but  also  of  approaches 
which  seem  to  work  well,  are  needed.  In  addition,  communication  as  to  what  software/data  rights 
resources  are  already  available  within  the  Department  would  be  useful.  Our  research  uncovered 
situations  in  which  the  same  software  or  data  rights  had  been  purchased  on  more  than  one 
occasion  because  of  the  lack  of  any  mechanism  whereby  the  availability  of  the  software  or  data 
rights  could  have  been  communicated  to  others  within  the  Department.  Some  form  of  library  or 
cataloguing  system  might  even  be  advisable  as  a  means  of  encouraging  that  DoD  take  advan¬ 
tage  of  the  reusability  of  certain  software,  and  of  communicating  that  DoD  already  possesses 
certain  data  rights  and  there  is  no  reason,  therefore,  to  purchase  them  again.  These  are  matters 
which  it  is  certainly  well  within  the  control  of  DoD  to  address. 

13.1.4  DoD  -  Industry  Communications 

In  the  course  of  preparing  this  report,  we  spoke  with  many  individuals,  from  both  government  and 
industry,  who  play  some  role  in  the  software/data  rights  procurement  process.  We  noted  that 
representatives  of  both  industry  and  government  are  quick  to  acknowledge  that  there  currently 


exist  many  problems  in  this  area.  Those  same  individuals  tend  to  point  an  accusing  finger  at  the 
other  side  as  the  culprit  responsible  for  these  problems.  Industry  people  say,  "the  government  is 
asking  for  too  much,  and  they  are  not  willing  to  pay  for  it."  The  government  people  say,  "we  need 
those  software  tools,  or  data,  or  rights  to  meet  our  needs",  or  "the  regulations,  or  this  policy,  or 
that  clause  requires  us  to  get  all  of  that  whether  we  need  it  or  not,  so  you  have  to  give  it  to  us." 
Unfortunately,  industry  has  become  somewhat  distrustful  about  what  government  people  say,  and 
the  government  people  sometimes  feel  the  same  way  about  industry  people. 

The  reality  of  today  is  that  many  firms  on  the  "cutting  edge"  of  software  technology  can  survive 
without  doing  business  with  the  government.  The  DoD  needs  the  latest  technology  in  order  to 
maintain  a  strong  defense  and  military  capability.  Thus,  it  seems  dear  that  in  many  cases,  DoD 
needs  industry  more  than  industry  needs  DoD.  Given  this  situation,  it  seems  incumbent  upon 
DoD  to  make  some  effort  to  open  up  and  improve  the  strained  lines  of  communication  between  it 
and  private  industry. 

Many  of  the  industry  people  we  spoke  with  indicated  that  they  would  welcome  the  opportunity  to 
sit  down  and  discuss  software/data  rights  procurement  issues  with  DoD  people  in  an  effort  to 
resolve  their  differences.  Indeed,  some  of  these  individuals  told  us  that  in  their  view  the  most 
useful  role  the  SEI  could  play  would  be  to  provide  a  forum  wherein  industry  and  government 
people  could  meet  to  discuss  software/data  rights  issues  in  an  objective,  rational  manner.  These 
people,  however,  also  expressed  a  lack  of  optimism  over  the  prospect  that  such  productive  com¬ 
munication  would  in  fact  oocur,  citing  incidents  such  as  DoD's  sudden  withdrawal  from  the  Rights 
in  Data  Technical  Working  Group  (RTDWG)  [13]  (a  study  which  DoD  had  itself  initiated),  and  the 
imposition  of  the  Air  Force’s  "Orr  Clause". 

Our  conclusion  is  that  industry  people  are  willing  to  meet  with  DoD  in  an  effort  to  resolve  dif¬ 
ferences  which  exist.  It  is  clearly  within  the  power  and  control  of  DoD  to  pursue  such  com¬ 
munications,  and  would  likely  be  one  of  the  most  beneficial  steps  DoD  could  take  toward  resolv¬ 
ing  many  of  its  software  licensing  problems. 

13.2  What  DoD  Has  Some  Control  Over 

13.2.1  DoO’s  Own  Acquisition  Regulations 

The  DoD  also  has  considerable  control  over  its  own  procurement  regulations  in  the  areas  of 
software  and  data  rights  (the  DoD  FAR  Supplement).  This  oontrol  is  tempered  somewhat  by  the 
limitations  imposed  by  the  FAR  and  relevant  legislation,  as  well  as  by  the  process  required  of 
DoD  to  adopt  new  regulations,  and  the  opportunity  of  industry  to  contest  newly  proposed  regula¬ 
tions  before  they  become  effective.  Nonetheless,  there  is  much  DoD  could  do  toward  adopting 
regulations  which  are  more  simplified,  uniform,  and  clear. 

Through  revision  of  its  own  acquisition  regulations,  the  DoD  could,  for  example,  resolve  issues 
such  as  government  ownership  of  copyright  by  adopting  an  assignment  approach,  and  concerns 


regarding  trademark  rights  in  words  such  as  Ada  by  property  registering  the  mark  and  complying 
with  the  requirements  as  discussed  in  Chapter  6.  Further,  it  would  be  relatively  easy  for  the  DoD 
to  address  any  issues  related  to  the  need  for  a  derivative  works  right  by  making  some  adjust¬ 
ments  to  its  definition  of  "unlimited  rights". 

As  has  been  noted  throughout  this  report,  the  DoD  acquisition  regulations  are  in  need  of  some 
revision  so  as  to  make  them  more  consistent  with  the  realities  of  modem  commercial  practice  as 
well  as  the  precepts  of  intellectual  property  law.  A  clearer,  more  succinct  delineation  of  the 
various  rights  packages  available,  and  of  the  situations  to  which  they  apply,  would  be  a  substan¬ 
tial  improvement.  The  regulations  could  be  shaped  so  as  to  allow  the  DoD  to  more  easily  enter 
escrowing  and  long  term  maintenance  agreements  where  necessary  and  appropriate  in  order  to 
secure  documentation,  tools,  CAD/CAM  programs  and  the  like  which  would  otherwise  remain 
unavailable  to  the  DoD.  In  general,  the  software/data  rights  regulations  could  be  revised  so  as  to 
better  reflect  the  economic  realities  of  the  software  industry  as  well  as  a  better  appreciation  of 
software  technology.  It  is  time  to  stop  treating  software  and  its  documentation  similar  to  the  way 
DoD  treats  technical  data.  The  economics  of  the  software  industry  are  simply  too  different  from 
the  economics  of  the  technical  data  situation  for  the  legal  rules  to  be  the  same.  The  policy 
reflected  in  the  newly  proposed  FAR  Subpart  27.4  [66]  would  provide  DoD  a  good  starting  point 
toward  devising  such  a  regulatory  policy  statement.  A  further  advantage  of  addressing  DoD’s 
software  licensing  problems  through  regulations  is  that  such  changes  could  be  made  without 
resort  to  legislative  or  litigation  activities. 

13.2.2  DoD  Policies  With  Respect  to  RFPs  and  Procurement  Practices 

DoD  could  also  do  much  to  improve  its  own  internal  policies  as  to  the  preparation  of  RFPs,  and 
other  aspects  of  DoD  procurement  practices.  The  Department  could  take  steps  toward  greater 
standardization,  and  increased  emphasis  on  maintenance/enhancement  issues  at  an  early  stage 
of  the  procurement  process  (as  was  discussed  in  Chapters  2  and  3).  Moreover,  this  is  an  area  in 
which  DoD  has  substantial  control  since  it  would  not  be  limited  by  the  notice  and  comment  re¬ 
quirements  which  would  accompany  the  adoption  of  new  regulations. 

13.2.3  Legislative  Reforms  and  Court  Action 

The  DoD  could  use  its  powerful  lobbying  abilities  to  seek  legislative  changes  if  it  thought  this 
necessary  to  improve  its  position  in  the  software/data  rights  procurement  area.  Areas  of  focus 
might  include  the  changes  to  the  Contract  Disputes  Act  to  shunt  all  data  rights  disputes  into  this 
framework  so  that  injunctive  relief  would  be  unavailable  to  contractors  in  software  disputes  (see 
Chapter  9)  or  the  Copyright  Act  to  get  software  exempted  from  the  Section  105  preclusion  against 
direct  government  ownership  of  copyrights  (see  Chapter  5).  Similarly,  the  government  could 
target  certain  areas  for  emphasis  by  its  legal  staff.  Test  cases  could  be  sought  in  an  effort  to  put 
forward  legal  theories  which  DoD  feels  are  important.  Resources  could  be  focused  in  these 
areas  in  an  effort  to  maximize  the  chances  that  DoD  would  prevail  as  to  these  legal  theories. 
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13.3  What  DoD  Has  Less  Direct  Control  Over 

As  has  been  discussed  throughout  this  report,  there  are  some  areas  over  which  DoD  has  little 
direct  control,  and  little  likelihood  of  making  a  direct  impact  regardless  of  the  amount  of  resources 
expended.  The  areas  in  which  it  seems  less  likely  that  DoD  would  be  successful  in  bringing 
about  direct  changes  include: 

(1)  Getting  competition  in  maintenance  of  proprietary  software  (see  Chapter  2). 

(2)  Obtaining  software  tools  in  which  a  private  firm  holds  a  proprietary  right  (see  Chapter  2 ). 

(3)  Obtaining  CAD/CAM  programs  from  private  firms  (see  Chapter  10.) 

The  rights  the  government  has  been  asking  for  in  this  regard  are  too  valuable  to  industry  to  be 
given  up  easily.  A  more  productive  approach  might  be  to  develop  a  mechanism  whereby  DoD 
could  more  easily  enter  escrowing  and  long  term  maintenance  agreements  providing  for  con¬ 
trolled  access  to  such  items.  Indeed,  such  an  approach  might  actually  be  beneficial  to  the  DoD  in 
that  under  such  an  arrangement  DoD  would  not  only  have  access  to  needed  documentation, 
code,  tools  and  the  like,  but  would  also  avoid  having  to  trouble  itself  with  storage,  cataloguing  and 
internal  access  concerns. 

Further,  through  such  a  method,  DoD  could  have  greater  access  to  improvements  in  the  tech¬ 
nology  and/or  means  of  maintaining  and  enhancing  that  technology,  and,  significantly,  would  not 
be  endangering  any  implied  warranties  which  might  otherwise  be  jeopardized  if  DoD  maintained 
or  modified  software  organically  or  through  competitive  reprocurement.  If  DoD  persists  in  assert¬ 
ing  that  it  must  have  ever  greater  rights  in  software,  software  tools,  CAD/CAMs,  and  software 
documentation,  it  may  find  it  has  'shot  itself  in  the  foot*.  Industry  response  is  likely  to  be  to 
withdraw  from  doing  business  with  DoD  or  to  only  sell  DoD  "okT  technology. 

Finally,  it  should  be  noted  that  the  challenge  of  trying  to  find  an  appropriate  way  to  acquire  and 
maintain  software  is  not  one  unique  to  the  DoD.  The  unique  nature  of  software  --  part  "writing," 
part"  machine"  --  has  caused  substantial  confusion  about  its  proper  treatment  in  many  areas  of 
the  law.  Property  conceptualizing  software  and  fashioning  a  set  of  legal  rules  to  deal  with  it  is 
extremely  difficult;  it  requires  a  deep  understanding  of  the  economics  of  the  software  industry  and 
of  the  realities  of  the  development  of  software  technology. 

One  of  the  things  that  makes  this  already  difficult  task  yet  more  difficult  is  that  the  economic  and 
technological  aspects  of  the  software  industry  are  not  static,  but  rather  are  rapidly  evolving. 
Software  development  has  long  been  a  very  labor-intensive  activity;  it  is  now  becoming  a  more 
capital  intensive  industry,  especially  with  the  development  of  powerful  software  development  tools 
and  environments.  There  would  be  some  advantage  to  DoD  in  encouraging  this  shift  to  a  more 
capital  intensive  production  process,  especially  in  terms  of  improvement  of  development  produc¬ 
tivity.  To  encourage  this  shift,  DoD  must,  however,  abandon  the  quasi-technical  data  orientation 
of  its  current  software  acquisition  policy. 
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Because  of  the  DoD’s  position  as  a  world  leader  in  supporting  the  development  and  use  of 
software  technology,  DoD  has  had  the  misfortune  of  confronting  a  great  many  software  problems 
before  they  have  rippled  through  other  parts  of  the  national  economy.  Unquestionably,  this 
creates  some  difficulties  for  DoD,  and  places  the  DoD  in  the  position  of  dealing  with  challenges 
that  are  often  without  precedent,  a  difficult  task  indeed.  On  the  other  hand,  this  situation  gives 
the  DoD  a  unique  opportunity  to  influence  the  direction  of  the  software  industry  in  the  future.  By 
addressing  the  many  challenges  placed  on  its  doorstep  by  the  software  industry,  the  DoD  can 
claim  a  strategic  position  on  the  leading  edge  of  the  development  of  software  technology. 
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APPENDIX  A 


Selected  Sections  of  the  Copyright  Law 


Section  101  -  Definitions 


As  used  in  this  title,  the  following  terms  and  their  variant  forms  mean  the  following: 


An  ’anonymous  work’  is  a  work  done  on  the  copies  or  phonorecords  of  which  no  natural 
person  is  identified  as  author. 


’Audiovisual  works*  are  works  that  consist  of  a  series  of  related  images  which  are 
intrinsically  intended  to  be  shown  by  the  use  of  machines  or  devices  such  as  projectors,  viewers, 
or  electronic  equipment,  together  with  accompanying  sound,  if  any  ,  regardless  of  the  nature  of 
the  material  objects,  such  as  films  or  tapes,  in  which  the  works  are  embodied. 


The  "best  edition”  of  a  work  is  the  edition,  published  in  the  United  States  at  any  time  before 
the  date  of  deposit,  that  the  Library  of  Congress  determines  to  be  most  suitable  for  its  purposes. 


A  person's  ’children*  are  that  person's  immediate  offspring,  whether  legitimate  or  not,  and 
any  children  legally  adopted  by  that  person. 


A  ’collective  work’  is  a  work,  such  as  a  periodical  issue,  anthology,  or  encyclopedia,  in 
which  a  number  of  contributions,  constituting  separate  and  independent  works  in  themselves,  are 
assembled  into  a  collective  whole. 


A  ’compilation’  is  a  work  formed  by  the  collection  and  assembling  of  reexisting  materials  or 
of  data  that  are  selected,  coordinated,  or  arranged  in  such  a  way  that  the  resulting  woik  as  a 
whole  constitutes  an  original  work  of  authorship.  The  term  ’compilation*  includes  collective 
works. 


A  ’computer  program*  is  a  set  of  statements  or  instructions  to  be  used  directly  or  indirectly 
in  a  computer  in  order  to  bring  about  a  certain  result. 


’Copies*  are  material  objects,  other  than  phonorecords,  in  which  a  work  is  fixed  by  any 
method  now  known  or  later  developed,  and  from  which  the  work  can  be  perceived,  reproduced, 
or  otherwise  communicated,  either  directly  or  with  the  aid  of  a  machine  or  device.  The  term 
’copies’  includes  the  material  object,  other  than  a  phonorecord,  in  which  the  work  is  first  fixed. 


’Copyright  owner”,  with  respect  to  any  one  of  the  exclusive  rights  comprised  in  a  copyright, 
refers  to  the  owner  of  that  particular  right. 


A  work  is  "created"  when  it  is  fixed  in  a  copy  or  phonorecord  for  the  first  time;  where  a  work 
is  prepared  over  a  period  of  time,  the  portion  ol  it  that  has  been  fixed  at  any  particular  time 
constitutes  the  work  as  of  that  time,  and  where  the  work  has  been  prepared  in  different  versions, 
each  version  constitutes  a  separate  work. 


A  "derivative  work’  is  a  work  based  upon  one  or  more  preexisting  works,  such  as  a 
translation,  musical  arrangement,  dramatization,  fidionalization,  motion  picture  version,  sound 
recording,  art  reproduction,  abridgment,  condensation,  or  any  other  form  in  which  a  work  may  be 
recast,  transformed,  or  adapted.  A  work  consisting  of  editorial  revisions,  annotations, 
elaborations,  or  other  modifications  which,  as  a  whole,  represent  an  original  work  of  authorship,  is 
a  "derivative  work". 


A  "device",  "machine",  or  "process"  is  one  now  known  or  later  developed. 


To  "display"  a  work  means  to  show  a  copy  of  it,  either  directly  or  by  means  of  a  film,  slide, 
television  image,  or  any  other  device  or  process  or,  in  the  case  of  a  motion  picture  or  other 
audiovisual  work,  to  show  individual  images  nonsequentially. 


A  work  is  "fixed"  in  a  tangible  medium  of  expression  when  its  embodiment  in  a  copy  or 
phonorecord,  by  or  under  the  authority  of  the  author,  is  sufficiently  permanent  or  stable  to  permit 
it  to  be  perceived,  reproduced,  or  otherwise  communicated  for  a  period  of  more  than  transitory 
duration.  A  work  consisting  of  sounds,  images,  or  both,  that  are  being  transmitted,  is  "fixed"  for 
purposes  of  this  title  if  a  fixation  of  the  work  is  being  made  simultaneously  with  its  transmission. 


The  terms  "including"  and  "such  as"  are  illustrative  and  not  limitative. 

A  "joint  work"  is  a  work  prepared  by  two  or  more  authors  with  the  intention  that  their 
contributions  be  merged  into  inseparable  or  interdependent  parts  of  a  unitary  whole. 


"Literary  works’  are  works,  other  than  audiovisual  works,  expressed  in  words,  numbers,  or 
other  verbals  or  numerical  symbols  or  indicia,  regardless  of  the  nature  of  the  material  objects, 
such  as  books,  periodicals,  manuscripts,  pho norecords,  film,  tapes,  disks,  or  cards,  in  which  they 
are  embodied. 


"Motion  pictures’  are  audiovisual  works  consisting  of  a  series  of  related  images  which, 
when  shown  in  succession,  impart  an  impression  of  motion,  together  with  accompanying  sounds, 
if  any. 


To  "perform"  a  work  means  to  recite,  render,  play,  dance,  or  act  it,  either  directly  or  by 
means  of  any  device  or  process  or,  in  the  case  of  a  motion  picture  or  other  audiovisual  work,  to 
show  its  images  in  any  sequence  or  to  make  the  sounds  accompanying  it  audible. 


"Phonorecords"  are  material  objects  in  which  sounds,  other  than  those  accompanying  a 
motion  picture  or  other  audiovisual  work,  are  fixed  by  any  method  now  known  or  later  developed, 
and  from  which  the  sounds  can  be  perceived,  reproduced,  or  otherwise  communicated,  either 
directly  or  with  the  aid  of  a  machine  or  device.  The  term  "phonerecords"  includes  the  material 
object  in  which  the  sounds  are  first  fixed. 
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"Pictorial,  graphic,  and  sculptural  works”  include  two-dimensional  and  three-dimensional 
works  of  fine,  graphic,  and  applied  art,  photographs,  prints  and  art  reproductions,  maps,  globes, 
charts,  technical  drawings,  diagrams,  and  models.  Such  works  shall  include  works  of  artistic 
craftsmanship  insofar  as  their  form  but  not  their  mechanical  or  utilitarian  aspects  are  concerned; 
the  design  of  a  useful  article,  as  defined  in  this  section,  shall  be  considered  a  pictorial,  graphic,  or 
sculptural  work  only  if,  and  only  to  the  extent  that,  such  design  incorporates  pictorial,  graphic,  or 
sculptural  features  that  can  be  identified  separately  from,  and  are  capable  of  existing 
independently  of,  the  utilitarian  aspects  of  the  article. 


A  "pseudonymous  work"  is  a  work  on  the  copies  or  phonorecords  of  which  the  author  is 
identified  under  a  fictitious  name. 


"Publication’  is  the  distribution  of  copies  or  phonorecords  of  a  work  to  the  public  by  sale  or 
other  transfer  of  ownership,  or  by  rental,  leasing,  or  lending.  The  offering  to  distribute  copies  or 
phonorecords  to  a  group  of  persons  for  purposes  of  further  distribution,  public  performance,  or 
public  disply,  constitutes  publication.  A  public  performance  or  display  of  a  work  does  not  of  itself 
constitute  publications. 


To  perform  or  display  a  work  "publicly"  means: 


(1)  to  perform  or  display  it  at  a  place  open  to  the  public  or  at  any  place  where  a 
substantial  number  of  persons  outside  of  a  normal  circle  of  a  family  and  its  social  acquaintances 
is  gathered;  or 


(2)  to  transmit  or  otherwise  communicate  a  performance  or  display  of  the  work  to  a  place 
specified  by  clause  (1)  or  to  the  public,  by  means  of  any  device  or  process,  whether  the 
members  of  the  public  capable  of  receiving  the  performance  or  display  receive  it  in  the  same 
place  or  in  separate  places  and  at  the  same  time  or  at  different  times. 


"Sound  recordings"  are  works  that  result  from  the  fixation  of  a  series  of  musical,  spoken,  or 
other  sounds,  but  not  including  the  sounds  accompanying  a  motion  picture  or  other  audiovisual 
work,  regardless  of  the  nature  of  the  material  objects,  such  as  disks,  tapes,  or  other 
phonorecords,  in  which  they  are  embodied. 


"State"  includes  the  District  of  Columbia  and  the  Commonwealth  of  Puerto  Rico,  and  any 
territories  to  which  this  title  is  made  applicable  by  an  Act  of  Congress. 


A  "transfer  of  copyright  ownership’  is  an  assignment,  mortgage,  exclusive  license,  or  any 
other  conveyance,  alienation,  or  hypothecation  of  a  copyright  or  of  any  of  the  exclusive  rights 
comprised  in  a  copyright,  whether  or  not  it  is  limited  in  time  or  place  of  effect,  but  not  including  a 
nonexclusive  license. 


A  "transmission  program*  is  a  body  of  material  that,  as  an  aggregate,  has  been  produced 
for  the  sole  purpose  of  transmission  to  the  public  in  sequence  and  as  a  unit. 


To  "transmit’  a  performance  or  display  is  to  communicate  it  by  any  device  or  process 
whereby  images  or  sounds  are  received  beyond  the  place  from  which  they  are  sent. 
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The  'United  States',  when  used  in  a  geographical  sense,  comprises  the  several  States,  the 
District  of  Columbia  and  the  Commonwealth  of  Puerto  Rico,  and  the  organized  territories  under 
the  jurisdiction  of  the  United  States  Government. 


A  "useful  article*  is  an  article  having  an  instrinsic  utilitarian  function  that  is  not  merely  to 
portray  the  appearance  of  the  article  or  to  convey  information.  An  article  that  is  normally  a  part  of 
a  useful  article  is  considered  a  'useful  article”. 


The  author's  "widow'  or  'widower'  is  the  author’s  surviving  spouse  under  the  law  of  the 
author’s  domicile  at  the  time  of  his  or  her  death,  whether  or  not  the  spouse  has  later  remarried. 


A  "work  of  the  United  States  Government’  is  a  work  prepared  by  an  officer  or  employee  of 
the  United  States  Government  as  part  of  that  person's  official  duties. 


A  "work  made  for  hire"  is: 


(1 )  a  work  prepared  by  an  employee  within  the  scope  of  his  or  her  employment;  or 


(2)  a  work  specially  ordered  or  commissioned  for  use  as  a  contribution  to  a  collective 
work,  as  a  part  of  a  motion  picture  or  other  audiovisual  work,  as  a  translation,  as  a  supplementary 
work,  as  a  compilation,  as  an  instructional  text,  as  a  test,  as  answer  material  for  a  test,  or  as  an 
atlas,  if  the  parties  expressly  agree  in  a  written  instrument  signed  by  them  that  the  work  shall  be 
considered  a  work  made  for  hire.  For  the  purposes  of  the  foregoing  senter,  a  'supplementary 
work’  is  a  work  prepared  for  publication  as  a  secondary  adjunct  to  a  work  by  another  author  for 
the  purpose  of  introducing,  concluding,  illustrating,  explaining,  revising,  commenting  upon,  or 
assisting  in  the  use  of  the  other  work,  such  as  forewords,  afterwords,  pictorial  illustrating,  maps, 
charts,  tables,  editorial  notes,  musical  arrangements,  answer  material  for  tests,  bibliographies, 
appendixes,  and  indexes,  and  an  'instructional  text"  is  a  literary,  pictorial,  or  graphic  work 
prepared  for  publication  and  with  the  purpose  of  use  in  systematic  instructional  activities. 


Section  102  -  Subject  Matter  of  Copyright:  In  General 


(a)  Copyright  protection  subsists,  in  accordance  with  this  title,  in  original  works  of 
authorship  fixed  in  any  tangible  medium  of  expression,  now  known  or  later  developed,  from  which 
they  can  be  perceived,  reproduced,  or  otherwise  communication,  either  directly  or  with  the  aid  of 
a  machine  or  device.  Works  of  authorship  include  the  following  categories: 

(1)  literary  works: 

(2)  musical  works,  including  any  accompanying  words; 

(3)  dramatic  works,  including  any  accompanying  music; 

(4)  pantomimes  and  choreographic  works; 

(5)  pictorial,  graphic,  and  sculptural  works; 

(6)  motion  pictures  and  other  audiovisual  works;  and 

(7)  sound  recordings. 


(b)  In  no  case  does  copyright  protection  for  an  original  work  of  authorship  extend  to  any 
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idea,  procedure,  process,  system,  method  of  operation,  concept,  principle,  or  discovery, 
regardless  of  the  form  in  which  it  is  described,  explained,  illustrated,  or  embodied  in  such  work. 


Section  103  •  Subject  Matter  of  Copyright:  Compilations  and  Derivative  Works 


(a)  The  subject  matter  of  copyright  as  specified  by  section  102  includes  compilations  and 
derivative  works,  but  protection  for  a  work  employing  preexisting  material  in  which  copyright 
subsists  does  not  extend  to  any  part  of  the  work  in  which  such  material  has  been  used  unlawfully. 


(b)  The  copyright  in  a  compilation  or  derivative  work  extends  only  to  the  material 
contributed  by  the  author  of  such  work,  as  distinguished  from  the  preexisting  material  employed 
in  the  work,  and  does  not  imply  any  exclusive  right  in  the  preexisting  material.  The  copyright  in 
such  work  is  independent  of,  and  does  not  affect  or  enlarge  the  scope,  duration,  ownership,  or 
subsistence  of,  any  copyright  protection  in  the  preexisting  material. 


Section  104  -  Subject  Matter  of  Copyright:  National  Origin 

(a)  Unpublished  Works.  The  works  specified  by  sections  102  and  103,  while 
unpublished,  are  subject  to  protection  under  this  title  without  regard  to  the  nationality  or  domicile 
of  the  author. 


(b)  Published  Works.  The  works  specified  by  section  102  and  103,  when  published, 
are  subject  to  protection  under  this  title  if  - 


(1 )  on  the  date  of  first  publication,  one  or  more  of  the  authors  is  a  national  or  domiciliary 
of  the  United  States,  or  is  a  national,  domiciliary,  or  sovereign  authority  of  a  foreign  nation  that  is 
a  party  to  a  copyright  treaty  to  which  the  United  States  is  also  a  party,  or  is  a  stateless  person, 
wherever  the  person  may  be  domiciled,  or 

(2)  the  work  is  first  published  in  the  United  States  or  in  a  foreign  nation  that,  on  the  date 
of  first  publication,  is  a  party  to  the  Universal  Copyright  Convention;  or 

(3)  the  work  is  first  published  by  the  United  Nations  or  any  of  its  specialized  agencies,  or 
by  the  Organization  of  American  States;  or 

(4)  the  work  comes  within  the  scope  of  a  Presidential  proclamation.  Whenever  the 
President  finds  that  a  particular  foreign  nation  extends,  to  works  by  authors  who  are  nationals  or 
domiciliaries  of  the  United  States  or  to  works  that  are  first  published  in  the  United  States, 
copyright  protection  on  substantially  the  same  basis  as  that  on  which  the  foreign  nation  extends 
protection  to  works  of  its  own  nationals  and  domiciliaries  and  works  first  published  in  that  nation, 
the  President  may  by  proclamation  extend  protection  under  this  title  to  works  of  which  one  or 
more  of  the  authors  is,  on  the  date  of  first  publication,  a  national,  domiciliary,  or  sovereign 
authority  ol  that  nation,  or  which  was  first  published  in  that  nation.  The  President  may  revise, 
suspend,  or  revoke  any  such  proclamation  or  impose  any  conditions  or  limitations  on  protection 
under  a  proclamation. 
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Section  105  •  Subject  Matter  of  Copyright:  United  States  Government  Works 


Copyright  protection  under  this  title  is  not  available  for  any  work  of  the  United  States 
Government,  but  the  United  States  Government  is  not  precluded  from  receiving  and  holding 
copyrights  transferred  to  it  by  assignment,  bequest,  or  otherwise. 


Section  106  -  Exclusive  Rights  in  Copyrighted  Works 


Subject  to  section  107  through  118,  the  owner  of  copyright  under  this  title  has  the  exclusive 
rights  to  do  and  to  authorize  any  of  the  following: 


(1 )  to  reproduce  the  copyrighted  work  in  copies  or  phonorecords; 


(2)  to  prepare  derivative  works  based  upon  the  copyrighted  work; 


(3)  to  distribute  copies  or  phonorecords  of  the  copyrighted  work  to  the  public  by  sale  or 
other  transfer  of  ownership,  or  by  rental,  lease,  or 


(4)  in  the  case  of  literary,  musical,  dramatic,  and  choreographic  works,  pantomimes,  and 
motion  pictures  and  other  audiovisual  works,  to  perform  the  copyrighted  work  publicly;  and 


(5)  in  the  case  of  literary,  musical,  dramatic,  and  choreographic  works,  pantomimes,  and 
pictorial,  graphic,  or  sculptural  works,  including  the  individual  images  of  a  motion  picture  or  other 
audiovisual  work,  to  display  the  copyrighted  work  publicly. 


Section  107  -  Limitations  on  Exclusive  Rights:  Fair  Use 


Notwithstanding  the  provisions  of  section  106,  the  fair  use  of  a  copyrighted  work,  including 
such  use  by  reproduction  in  copies  or  phonorecords  or  by  any  other  means  specified  by  that 
section,  for  purposes  such  as  criticism,  comment,  news  reporting,  teaching  (including  multiple 
copies  for  classroom  use),  scholarship,  or  research,  is  not  an  infringement  of  copyright.  In 
determining  whether  the  use  made  of  a  work  in  any  particular  case  is  a  fair  use  the  factors  to  be 
considered  shall  include  • 


(1)  the  purpose  and  character  of  the  use,  including  whether  such  use  is  of  a  commercial 
nature  or  is  for  nonprofit  educational  purposes; 


(2)  the  nature  of  the  copyrighted  work; 


(3)  the  amount  nd  substantiality  of  the  portion  used  in  relation  to  the  copyrighted  work  as  a 
whole;  and 
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(4)  the  effect  of  the  use  upon  the  potential  market  for  or  value  of  the  copyrighted  work. 


Section  106  •  Limitations  on  Exclusive  Rights:  Reproduction  by  Libraries  and  Archives 


(a)  Notwithstanding  the  provisions  of  section  106,  it  is  not  an  infringement  of  copyright 
for  a  library  or  archives,  or  any  of  its  employees  acting  within  the  scope  of  their  employment,  to 
reproduce  no  more  than  one  copy  or  phonorecord  of  a  work,  or  to  distribute  such  copy  or 
phonorecord,  under  the  conditions  specified  by  this  section,  if  - 


(1)  the  reproduction  or  distribution  is  made  without  any  purpose  of  direct  or  indirect 
commercial  advantage; 


(2)  the  collections  of  the  library  or  archives  are  (i)  open  to  the  public,  or  (ii)  available  not 
only  to  researches  affiliated  with  the  library  or  archives  or  with  the  institution  of  which  it  is  a  part, 
but  also  to  other  persons  doing  research  in  a  specialized  field;  and 

(3)  the  reproduction  or  distribution  of  the  work  includes  a  notice  of  copyright. 

(b)  The  rights  or  reproduction  and  distribution  under  this  section  apply  to  a  copy  or 
phonorecord  of  an  unpublished  work  duplicated  in . 


Section  117  -  Limitations  on  Exclusive  Rights:  Computer  Programs 


Notwithstanding  the  provisions  of  section  106,  it  is  not  an  infringement  for  the  owner  of  a 
copy  of  a  computer  program  to  make  or  authorize  the  making  of  another  copy  or  adaptation  of 
that  computer  program  provided  that; 


(1)  that  such  a  new  copy  or  adaptation  is  created  as  an  essential  step  in  the  utilization  of 
the  computer  program  in  conjunction  with  a  machine  and  that  it  is  used  in  no  other  manner,  or 


(2)  that  such  new  copy  or  adaptation  is  for  archival  purposes  only  and  that  all  archival 
copies  are  destroyed  in  the  event  that  continued  possession  of  the  computer  program  should 
cease  to  be  rightful. 


Any  exact  copies  prepared  in  accordance  with  the  provisions  of  this  section  may  be  leased, 
sold,  or  otherwise  transferred,  along  with  the  copy  from  which  such  copies  were  prepared,  only  as 
part  of  the  lease,  sale,  or  other  transfer  of  all  rights  in  the  program.  Adaptations  so  prepared  may 
be  transferred  only  with  the  authorization  of  the  copyright  owner. 


Section  118  -  Scope  of  Exclusive  Rights:  Use  of  Certain  Works  in  Connection  with 
Noncommercial  Broadcasting 
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(a)  The  exclusive  rights  provided  by  section  1 06  shall,  with  respect  to  the  works  specified 
by  subsection  (b)  and  the  activities  specified  by  subsection  (d),  be  subject  to  the  conditions  and 
limitations  prescribed  by  this  section. 

(b)  Not  later  than  thirty  days  after  the  Copyright  Royalty  Tribunal  has  been  constituted  in 
accordance  with  section  802,  the  Chairman  of  the  Tribunal  shall  cause  notice  to  be  published  in 
the  Federal  Register  of  the  initiation  of  proceedings  for  the  purpose  of  determining  reasonable 
terms  and  rates  of  royalty  payments  for  the  activities  specified  in  subsection  (d)  with  respect  to 
published  nondramatic  musical  works  and  published  pictorial,  graphic,  and  sculptural  works ... 


CHAPTER  2.  -  COPYRIGHT  OWNERSHIP  AND  TRANSFER 


Section  201  -  Ownership  of  Copyright 


(a)  Initial  Ownership.  Copyright  in  a  work  protected  under  this  title  vests  initially  in  the 
author  or  authors  of  the  work.  The  authors  of  a  joint  work  are  co-owners  of  copyright  in  the  work. 


(b)  Works  Made  for  Hire.  In  the  case  of  a  work  made  for  hire,  the  employer  or  other 
person  for  whom  the  work  was  prepared  is  considered  the  author  for  purposes  of  this  title  and. 
unless  the  parties  have  expressly  agreed  otherwise  in  a  written  instalment  signed  by  them,  owns 
all  of  the  rights  comprised  in  the  copyright. 


(c)  Contributions  to  Collective  Works.  Copyright  in  each  separate  contribution  to  a 
collective  work  is  distinct  from  copyright  in  the  collective  work  as  a  whole,  and  vests  initially  in  the 
author  of  the  contribution.  In  the  absence  of  an  express  transfer  of  the  copyright  or  of  any  rights 
under  it,  the  owner  of  copyright  in  the  collective  woik  is  presumed  to  have  acquired  only  the 
privilee  of  reproducing  and  distributing  the  contribution  as  part  of  that  particular  collective  work, 
any  revision  of  that  collective  work,  and  any  later  collective  work  in  the  same  series. 


(d)  Transfer  of  ownership. 


(1)  The  ownership  of  a  copyright  may  be  transferred  in  whole  or  in  part  by  any  means  of 
conveyance  or  by  operation  of  law,  and  may  be  bequeathed  by  will  or  pass  as  personal  property 
by  the  applicable  laws  of  intestate  succession. 


(2)  Any  of  the  exclusive  rights  comprised  in  a  copyright,  including  any  subdivision  of  any  of 
the  rights  specified  by  section  106,  may  be  transferred  as  provided  by  clause  (1)  and  owned 
separately.  The  owner  of  any  particular  exclusive  right  is  entitled,  to  the  extent  of  that  right,  to  all 
of  the  protection  and  remedies  accorded  to  the  copyright  owner  by  this  title. 


(e)  Involuntary  Transfer. 


When  an  individual  author's  ownership  of  a  copyright,  or  of  any  of  the  exclusive  rights 
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under  a  copyright,  has  not  previously  been  transferred  voluntarily  by  that  individual  author,  no 
action  by  any  governmental  body  or  other  official  or  organization  purporting  to  seize,  expropriate, 
transfer,  or  exercise  rights  of  ownership  with  respect  to  the  copyright,  or  any  of  the  exclusive 
rights  under  a  copyright,  shall  be  given  effect  under  this  title  except  as  provided  under  Title  1 1 
[relating  to  bankruptcy]. 


Selected  Sections  of  the  Copyright  Law  137 


vV 


APPENDIX  B 


DoD  Procurement  Regulations 

27.403  Acquisition  of  Rights  in  Technical  Data. 


27.403-1  Background. 


(a)  Government’s  Interest  in  Technical  Data.  The  Government  has  extensive  needs  for 
many  kinds  of  technical  data.  Its  needs  may  well  exceed  those  cf  private  commercial 
customers.  For  defense  purposes,  millions  of  separate  equipment  and  supply  items,  ranging 
from  standard  to  unique  types,  must  be  acquired,  operated,  and  maintained,  often  at  points 
remote  from  the  source  of  supply.  Functions  requiring  varied  kinds  of  technical  data  include 
training  of  personnel,  overhaul  and  repair,  cataloging,  standardization,  inspection  and  quality 
control,  packaging,  and  logistics  operations.  Technical  data  resulting  from  research  and 
development  contracts  must  be  obtained,  organized  and  disseminated  to  many  different 
users.  Finally,  the  Government  must  make  technical  data  widely  available  in  the  form  of 
contract  specifications  in  order  to  obtain  competition  among  its  suppliers,  and  thus  further 
economy  in  Government  procurement. 


(b)  Contractor’s  Interest  in  Technical  Data.  Commercial  organizations  have  a  valid 
economic  interest  in  technical  data  pertaining  to  items,  components,  or  processes  which  they 
have  developed  at  their  own  expense.  Such  technical  data  is  often  closely  held  because  its 
disclosure  to  competitors  could  jeopardize  the  competitive  advantage  it  was  developed  to 
provide.  Public  disclosure  of  such  technical  data  can  cause  serious  economic  hardship  to  the 
originating  company. 


(c)  The  Balancing  of  Interests. 


(1)  It  is  apparent  that  there  is  no  necessary  correlation  between  the  Government's 
need  for  technical  data  and  its  contractors’  economic  interest  therein.  However,  in  balancing 
the  Government's  requirements  for  technical  data  against  the  contractor’s  interest  in 
protecting  his  technical  data,  it  should  be  recognized  that  there  may  be  a  considerable 
identity  of  interest.  This  is  particularly  true  in  the  case  of  innovative  contractors  who  can  best 
be  encouraged  to  develop  at  private  expense  items  of  military  usefulness  where  their  rights  in 
such  items  are  scrupulously  protected. 


(2)  It  is  equally  important  that  the  Government  foster  successful  contractual 
relationships  and  encourage  a  ready  flow  of  data  essential  to  Government  needs  by  confining 
its  acquisitions  of  technical  data  to  cases  of  actual  need.  Certainly  the  Government  must  not 
be  barred  from  bargaining  and  contracting  to  obtain  such  technical  data  as  it  needs,  even 
though  that  technical  data  may  normally  not  be  disclosed  in  commercial  practice.  Moreover, 
when  the  Government  pays  for  research  and  development  work  which  produces  new 
knowledge,  products,  or  processes,  it  has  an  obligation  to  foster  technological  progress 
through  wide  dissemination  of  the  new  and  useful  information  derived  from  such  work  and 
where  practicable  to  provide  competitive  opportunities  for  supplying  the  new  products  and 
utilizing  the  new  processes. 
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(3)  At  the  same  time,  acquiring,  maintaining,  storing,  retrieving,  and  distributing 
technical  data  in  the  vast  quantities  generated  by  modem  technology  is  costly  and 
burdensome  for  the  Government.  For  this  reason  alone,  K  would  be  necessary  to  control 
closely  the  extent  and  nature  of  technical  data  procurement.  Such  control  is  also  necessary 
to  insure  Government  respect  for  its  contractors’  economic  interest  in  technical  data  relating 
to  their  privately  developed  items.  The  policies  and  procedures  of  this  subsection  are  framed 
in  the  light  of  these  considerations. 


27.403-2  Policy. 


(a)  General. 


(1)  It  is  the  policy  of  the  Department  of  Defense  to  acquire  only  such  technical  data 
rights  as  are  essential  to  meet  Government  needs. 


(2)  In  deciding  whether  to  acquire  technical  data  for  future  acquisitions  so  that  all  such 
acquisitions  can  be  made  on  a  competitive  basis  tc  the  maximum  practicable  extent,  the 
provisions  of  this  section  shall  govern. 


(b)  Unlimited  Rights  Technical  Data.  Technical  data  in  the  following  categories  shall  be 
acquired  with  unlimited  rights. 


(1)  Technical  data  resulting  directly  from  performance  of  experimental,  developmental, 
or  research  work  which  was  specified  as  an  element  of  performance  in  a  Government 
contract  or  subcontract; 


(2)  Technical  data  necessary  to  enable  others  to  manufacture  end-items,  components 
and  modifications,  or  to  enable  them  tc  perform  processes,  when  the  end-items,  components, 
modifications  or  processes  have  been,  or  are  being,  developed  under  Government  contracts 
or  subcontracts  in  which  experimental,  developmental  or  research  work  was  specified  as  an 
element  of  contract  performance,  except  technical  data  pertaining  to  items,  components  or 
processes  developed  at  private  expense; 


(3)  Technical  data  prepared  or  required  to  be  delivered  under  any  Government  contract 
or  subcontract  and  constituting  corrections  or  changes  to  Government-furnished  data. 


(4)  Technical  data  pertaining  to  end-items,  components  or  processes,  prepared  or 
required  to  be  delivered  under  any  Government  contract  or  subcontract,  for  the  purpose  of 
identifying  sources,  size,  configuration,  mating  and  attachment  characteristics,  functional 
characteristics  and  performance  requirements  Cform,  fit  and  function"  data,  e.g.,  specification 
control  drawings,  catalog  sheets,  envelope  drawings,  etc.); 


(5)  Manuals  or  instructional  materials  prepared  or  required  to  be  delivered  under  a 
Government  contract  or  subcontract  for  installation,  operation,  maintenance  or  training 
purposes;  and 
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(6)  Technical  data  which  is  in  the  public  domain  or  has  been  or  is  normally  released  cr 
disclosed  by  the  contractor  or  subcontractor  without  restriction  on  further  disclosure.  "In  the 
public  domain*  means  available  to  the  public  without  copyright  or  other  restriction  of  any  kind. 


(c)  Limited  Rights  Technical  Data. 


(1)  Except  as  provided  in  paragraph  ()  above,  unpublished  technical  data  pertaining  to 
items,  components  or  processes  developed  at  private  expense  will  be  acquired  with  limited 
rights,  provided  that  the  data  is  identified  as  limited  rights  data  in  accordance  with 
subparagraph  (b)(2)  of  the  clause  at  52.227-7013,  Rights  in  Technical  Data  and  Computer 
Software.  Unpublished,  as  applied  to  technical  data  and  computer  software  documentation, 
means  that  which  has  not  been  released  to  the  public  nor  been  furnished  to  others  without 
restriction  on  further  use  or  disclosure. 


(2)  It  should  be  clearly  understood  that  the  above  statement  of  policy  is  a  recital  of 
rights  to  be  acquired  in  technical  data.  Neither  the  foregoing  statement  of  technical  data 
rights  policy,  nor  its  implementing  subparagraphs  (b)(1)  and  (2)  of  the  clause  at  52.227-7013, 
Rights  in  Technical  Data  and  Computer  Software,  establishes  technical  data  requirements  for 
a  particular  contract.  It  should  also  be  noted  that  technical  data  pertaining  to  items, 
components  or  processes  developed  at  private  expense  may  be  called  for,  required,  or 
otherwise  furnished  under  subparagraphs  (b)(1),  (3),  (4),  (5),  and  (6)  above  and,  as  such,  it 
will  be  acquired  with  unlimited  rights.  Contract  clauses  and  the  schedule  establish  the  form 
and  type  of  technical  data  to  be  furnished;  the  categories  into  which  such  technical  data  fall, 
determine  the  rights  to  be  obtained  by  the  Government  to  use  or  publish  such  technical  data. 


(d)  Predetermination  of  Rights  in  Technical  Data. 


(I)(i)  When  the  Government  needs  technical  data  with  unlimited  rights,  any  data  which 
the  offeror  intends  to  deliver  with  limited  rights  pursuant  to  paragraph  (c)  above  should  be 
identified  prior  to  contract  award,  if  feasble,  and  an  agreement  with  respect  thereto  shall  be 
incorporated  in  the  contract.  This  procedure  is  called  predetermination  of  rights  in  technical 
data. 


(ii)  The  procedure  may  be  initiated  by  the  contracting  officer  or  an  offeror  during  the 
negotiation  of  a  negotiated  contract.  In  order  to  be  productive,  the  procedure  should  apply 
only  to  that  technical  data  for  which  rights  may  practicably  be  identified.  Although  the 
agreement  may  also  cover  technical  data  to  be  delivered  with  unlimited  rights,  in  no  case 
shall  the  procedure  be  used  to  require  the  contractor  to  furnish,  with  unlimited  rights, 
technical  data  which  he  is  entitled  to  furnish  with  limited  rights  under  the  policy  in  paragraph 
(c)  above.  The  contracting  officer  shall  consult  his  counsel  as  fully  as  possible  in  determining 
whether  to  use  the  procedure  and  in  connection  with  the  various  steps  of  the  procedure. 


(2)  Any  agreements  reached  shall  be  incorporated  in  the  Schedule  of  the  contract 
directly  or  by  reference  and  shall  describe  specifically  the  technical  data  which  may  be 
furnished  with  limited  rights  pursuant  to  paragraph  (c)  above.  The  contracting  officer  may, 
however,  review  the  technical  data  asserted  to  be  limited  rights  data  to  determine  whether  to 
invoke  the  procedures  of  paragraph  (f)  below  to  negotiate  to  purchase  unlimited  rights  in  any 
of  the  technical  data,  or  adopt  some  alternative  such  as  to~ 
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(i)  delete  or  modify  the  requirement  for  the  technical  data  in  which  the  Government 
would  need  unlimited  rights  if  it  were  ordered,  or 


(ii)  modify  the  specifications  so  as  not  to  require  or  permit  the  use  of  the  item, 
component  or  process  covered  by  the  limited  rights  data;  or 


(iii)  include  a  contractual  option  to  acquire  unlimited  rights.  (3)  When  the 
predetermination  of  rights  in  technical  data  procedure  is  to  be  used,  include  the  provision  at 
52.227-7014,  Predetermination  of  Rights  in  Technical  Data,  in  the  Request  for  Proposals. 


(4)  If  completion  of  predetermination  proves  impracticable  before  award  or  if 
contractual  requirements  relating  to  design  or  technical  data  items  are  changed  during  the 
course  of  a  contract,  an  appropriate  provision  shall  be  included  in  the  contract,  requiring  the 
contractor  to  complete  the  identification  of  limited  rights  with  respect  to  that  technical  data 
listed  in  the  solicitation  for  which  predetermination  was  proposed,  or  to  identify  limited  rights 
technical  data  relating  to  the  changed  requirements. 


(e)  Subcontracts.  It  is  the  policy  of  the  Department  of  Defense  that  prime  contractors 
and  higher-tier  subcontractors  shall  not  use  their  power  to  award  subcontracts  as  economic 
leverage  to  acquire  rights  in  the  technical  data  of  their  subcontractors  for  themselves. 
Accordingly,  a  subcontractor  who  would  have  the  right  pursuant  to  paragraph  (c)  above  to 
furnish  technical  data  with  limited  rights,  may  furnish  such  limited  rights  data  directly  to  the 
Government  rather  than  through  the  prime  contractor. 


(f)  Specific  Acquisition  of  Unlimited  Rights  in  Technical  Data. 


(1)  Notwithstanding  paragraph  (c)  above  or  any  other  provision  of  this  subsection  the 
Government  may  acquire  unlimited  rights  in  any  limited  rights  technical  data  by  means  of 
negotiation  with  an  individual  contractor  or  subcontractor,  or  as  a  part  of  a  competition  among 
several  contractors  or  subcontractors.  Such  individual  negotiation  or  competition  may  be 
conducted  either  by  the  Government,  or  upon  Government  request  by  the  prime  contractor  or 
higher-tier  subcontractor.  Such  unlimited  rights  in  technical  data  shall  be  stated  in  the 
contract  schedule  as  a  separate  item  and  shall  be  separately  priced.  Unlimited  rights  in 
technical  data  shall  not  be  acquired  under  this  paragraph  unless  it  is  determined  after  a 
finding  upon  a  documented  record  that  component,  or  process  to  which  the  technical  data 
pertains; 


(ii)  there  is  no  suitable  item,  component  or  process  of  alternate  design  or  availability; 


(iii)  the  item  or  component  can  be  manufactured  or  the  process  performed  through  the 
use  of  such  technical  data  by  other  competent  manufacturers,  without  the  need  for  additional 
technical  data  which  cannot  be  purchased  reasonably  or  is  not  readily  obtained  by  other 
economic  means;  and 


(iv)  anticipated  net  savings  in  reprocurements  will  exceed  the  acquisition  cost  of  the 
technical  data  and  rights  therein. 
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(2)  The  analysis  and  findings  referred  to  in  subparagraph  (b)(1)  above  shall  specifically 
identify  each  item,  component  or  process  and  the  particular  technical  data  therefor  which  is  to 
be  purchased. 


(3)  When  all  technical  data  is  to  be  acquired  under  any  contract  with  unlimited  rights  in 
accordance  with  the  findings  of  paragraph  (f) 


(1)  above,  the  clause  at  52.227-701 5,  Rights  in  Technical  Data  -  Specific  Acquisition, 
shall  be  used. 


(4)(i)  In  addition  to  the  acquisition  of  unlimited  rights  in  technical  data  as  authorized  in 
paragraph  (f)  (1)  above,  there  will  be  situations  when  it  is  in  the  best  interest  of  the 
Government  to  acquire  from  subcontractors  repair  parts  or  components  by  direct  sale  to  the 
Government. 


(ii)  The  clause  at  52.227-7017,  Rights  in  Technical  Data  ~  Major  System  and 
Subsystem  Contractor,  may  be  used  in  contracts  for  major  systems  or  major  subsystems 
involving  estimated  program  expenditures  in  excess  of  $50  million  of  RDT&E  funds  or  in 
excess  of  $200  million  of  production  funds.  When  this  clause  is  used,  any  compensation  the 
contractor  requires  for  the  right  the  subcontractor  will  have  to  use  his  limited  rights,  technical 
data  shall  be  included  In  the  price  of  the  prime  contract.  Also,  the  Government  shall  have  the 
right  to  purchase  such  items  direct  from  manufacturing  subcontractors  without  the  payment, 
either  directly  of  any  fee  or  royalty  to  the  prime  contractor,  or  as  pari  of  the  purchase  price, 
for  use  of  the  prime  contractor's  technical  data. 


(iii)  For  the  purpose  of  applying  the  foregoing  policy,  the  following  definitions  shall  be 
utilized:  A  major  system  is  a  composite  of  equipment,  skills,  and  techniques  capable  of 
performing  and/or  supporting  an  operational  role  which  required  or  will  require  research, 
development,  test  and  evaluation  investment  or  design,  development,  test  and  evaluation 
investment  estimated  in  excess  of  $50  million  or  total  production  investment  estimated  in 
excess  of  $200  million.  A  major  subsystem  is  a  major  functional  part  of  a  major  system  (as 
defined  above)  which  is  essential  to  operational  completeness.  Examples  are:  airframe, 
propulsion,  armament,  guidance,  and  communication.  A  major  system  or  major  subsystem 
contractor  includes  an  associate  contractor  defined  as  a  prime  contractor  to  the  Government 
for  developing  and/or  producing  subsystems,  equipment,  or  components  meeting 
specifications  prepared  by  a  contractor  performing  one  or  more  of  the  functions  of  systems 
engineering  for  a  major  system  (as  defined  above). 


(g)  Notice  of  Certain  Limited  Rights. 


(1)  Whether  or  not  the  procedure  of  paragraph  (d)  above  for  predetermination  of  rights 
in  technical  data  is  used,  if  continuing  information  is  desired  under  a  contract  about  a 
contractor's  intention  to  use  in  the  performance  of  the  contract  any  item,  component,  or 
process  for  which  technical  data  would  be  subject  to  limited  rights  in  accordance  with  the 
policy  of  paragraph  (c)  above,  the  contractor  may  be  required  to  advise  the  contracting  officer 
of  this  fact  promptly  (see  subparagraph  27.412(a)(2)  and  Alternate  I  to  the  clause  at 
52.227-7013,  Rights  in  Technical  Data  and  Computer  Software).  If  posstole,  the  schedule 
should  indicate  the  specific  areas  pertaining  to  which  limited  rights  data  is  of  concern  and  the 
notice  requirement  should  be  restricted  to  those  areas  of  concern. 
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(2)  No  such  advice  shall  be  required  as  to  items,  components,  or  processes  tor  which 
notice  was  previously  given  pursuant  to  the  predetermination  procedure  in  the  same  contract, 
or  with  respect  to  standard  commercial  items  which  are  manufactured  by  more  than  one 
source  of  supply.  No  contracting  officer  approval  under  this  clause  is  necessary  for  the 
contractor  to  use  any  item,  component,  or  process,  identified  pursuant  to  this  requirement,  in 
the  performance  of  the  contract. 


(3)  If  the  contracting  officer  agrees  that  under  the  policy  stated  in  paragraph  (c)  above 
such  technical  data  would  be  subject  to  limited  rights,  he  may  then  determine  whether  to 
invoke  the  procedure  of  paragraph  (f)  above,  to  negotiate  for  the  purchase  of  unlimited  rights 
in  such  data  or  to  adopt  other  suitable  alternatives.  The  contract  shall  be  amended  to  reflect 
any  changes  required  by  these  procedures. 


27.403-3  Procedures. 


(a)  Deviations.  Extension  of  the  six-month  period  of  subparagraph  27.403-3(d)(2) 
below  shall  be  processed  under  the  authority  of  FAR  Section  1.403.  Other  deviations  to 
Section  27.403  and  from  the  clauses  prescribed  for  use  herein  shall  be  processed  in 
accordance  with  the  procedures  in  FAR  Section  1-404. 


(b)  Establishing  the  Government's  Rights  to  Use  Technical  Data. 


All  technical  data  specified  in  a  contract  or  subcontract  for  delivery  thereunder  shall  be 
acquired  subject  to  the  rights  established  in  the  appropriate  Rights  in  Technical  Data  clauses. 
Except  as  provided  in  FAR  Section  48.105  and  in  FAR  Subpart  36.6  no  other  clauses, 
directives,  standards,  specifications  or  other  implementation  shall  be  included,  directly  or  by 
reference,  to  enlarge  or  diminish  such  rights.  The  Government’s  acceptance  of  technical 
data  subject  to  limited  rights  does  not  inpair  any  rights  in  such  data  to  which  the  Government 
is  otherwise  entitled  or  impair  the  Government's  right  to  use  similar  or  identical  data  acquired 
from  other  sources. 


(c)  Marking  of  Technical  Data. 


(1)  Technical  data  delivered  to  the  Government  pursuant  to  any  contract  requirement 
shall  be  marked  with  the  number  of  the  prime  contract,  except  as  provided,  in  Subparagraph 
27.434-2(0(2),  and  the  name  of  the  contractor  and  any  subcontractor  who  generated  the 
technical  data.  Each  piece  of  technical  data  submitted  with  limited  rights  shall  also  be 
marked  with- 


(i)  the  authorized  restrictive  legend, 

(ii)  an  indication  (for  example,  by  circling,  underscoring,  or  a  note)  of  that  portion  of  the 
piece  of  technical  data  to  which  the  legend  is  applicable,  and 

(iii)  an  explanation  of  the  indication  used  to  identify  limited  rights  data. 
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Hie  Government  shall  include  such  identifying  markings  on  all  reproductions  thereof, 
unless  the  Government  cancels  such  markings  pursuant  to  subparagraphs  (c)(2),  (d)(3),  or 
(d)(4)  below. 


(2)  The  contractor  has  the  responsibility  to  assure  that  no  restrictive  markings  are 
placed  on  technical  data  except  in  accordance  with  the  'Rights  in  Technical  Data  and 
Computer  Software’  clause  at  52.227-7013.  Copyright  notices  as  specified  in  Title  17  United 
States  Code,  Sections  401  and  402,  are  not  considered  ’restrictive  markings*. 


When  the  clause  at  52.227-7013,  ’Rights  in  Technical  Data  and  Computer  Software’, 
is  required  by  27.412(a),  the  clause  at  52.227-7018,  'Restrictive  Markings  on  Technical 
Data’,  shall  also  be  included  in  the  contract.  The  contractor's  procedures  required  by  this 
clause  shall  be  reviewed  periodically  by  the  Contract  Administration  Office.  In  addition  to  the 
rights  afforded  to  the  Government  by  the  clause  at  52.227-7018,  ’Restrictive  Markings  on 
Technical  Data*,  the  following  actions  are  available  to  insure  proper  marking  of  technical 
data: 


(i)  The  procedures  in  paragraph  (d),  'Removal  of  Unauthorized  Markings’,  of  the 
clause  at  52.227-7013,  may  be  invoked  H  the  contractor  fails  to  follow  procedures  required  by 
the  clause  at  52.227-7013,  Rights  In  Technical  Data  and  Computer  Software,  or  fails  to 
correct  deficiencies  within  a  specified  time. 


(ii)  Failure  to  follow  proper  marking  procedures  may  also  be  deemed  to  render 
technical  data  nonconforming  and  subject  to  FAR  Section  46.102  and  to  withholding  of 
payments  under  the  Technical  Data-Withholding  of  Payments’  clause. 


(iii)  When  a  pre-award  survey  is  requested  by  the  purchasing  office,  the  quality 
assurance  review  shall  include  as  an  item  of  special  inquiry  an  examination  of  the 
prospective  contractor’s  procedures  for  complying  with  the  ’Restrictive  Markings  on  Technical 
Data*  clause. 


(iv)  The  contractor's  procedures  for  complying  with  the  ’Restrictive  Markings  on 
Technical  Data”  clause  shall  be  reviewed  when  holding  post-award  conferences  pursuant  to 
FAR  Subpart  42. 


(d)  Unmarked  or  Improperly  Marked  Technical  Data. 


(1)  The  Government  shall  have  the  right  to  require  the  contractor  to  furnish  clear  and 
convincing  evidence  of  the  propriety  of  any  restrictive  markings  used  by  the  contractor  on 
data  furnished  to  the  Government  under  contract. 


(2)  Technical  data  received  without  a  restrictive  legend  shall  be  deemed  to  have  been 
furnished  with  unlimited  rights.  However,  within  six  months  after  delivery  cf  such  data  the 
contractor  may  request  permission  to  place  restrictive  markings  on  such  data  at  his  own 
expense  and  the  Government  may  so  permit  if  the  oontractor- 
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(i)  demonstrates  that  the  omission  of  the  restrictive  marking  was  inadvertent, 

(ii)  establishes  pursuant  to  subparagraph  (d)(1)  above  that  the  use  of  the  markings  is 
authorized,  and 

(iii)  relieves  the  Government  of  any  liability  with  respect  to  such  technical  data  (see 
Paragraph  27.403-3(a)). 


(3)  If  technical  data  which  the  contractor  is  not  authorized  by  the  contract  to  furnish 
with  limited  rights  is  received  with  restrictive  markings,  the  technical  data  shall  be  used  with 
limited  rights  pending  written  inquiry  to  the  contractor.  If  no  response  to  an  inquiry  has  been 
received  within  60  days,  or  if  the  response  fails  to  substantiate  by  clear  and  convincing 
evidence  that  the  markings  were  authorized,  the  cognizant  Government  personnel  shall 
cancel  or  ignore  such  markings,  notify  the  contractor  accordingly  in  writing,  and  thereafter 
may  use  such  technical  data  with  unlimited  rights. 


(V)  If  technical  data  which  the  contractor  is  authorized  by  the  contract  to  furnish  with 
limited  rights  is  received  with  restrictive  markings  not  in  the  form  prescribed  by  the  contract, 
the  technical  data  shall  be  used  with  limited  rights,  and  the  contractor  shall  be  required  by 
written  notice  to  correct  the  markings  to  conform  with  those  specified  in  the  contract.  If  the 
contractor  fails  to  so  correct  the  markings  within  60  days  after  notice.  Government  personnel 
may  correct  or  cancel  the  markings,  so  notify  the  contractor  in  writing,  and  thereafter  use  the 
technical  data  accordingly. 


(e)  Technical  Data  Furnished  on  a  Restricted  Basis  in  Support  of  a  Proposal.  When 
the  contracting  officer  contemplates  awarding  a  contract  on  a  solicited  or  unsolicited  proposal 
which  was  offered  on  a  restricted  basis  (see  FAR  Section  5.413  and  FAR  Section  15.509),  he 
shall  ascertain  whether  to  acquire  rights  to  use  all  or  part  of  the  technical  data  furnished  with 
the  proposal.  If  such  rights  are  desired,  the  contracting  officer  shall  negotiate  with  the  offeror 
in  accordance  with  the  policies  set  forth  in  this  Section  27.403.  If  the  offeror  agrees  to  furnish 
the  technical  data  under  the  contract,  the  appropriate  clause  at  52.227-7013,  Rights  in 
Technical  Data  and  Computer  Software,  shall  be  inserted  in  the  contract,  and  the  contract 
shall  identify  the  technical  data  to  be  covered  by  the  clause  as  provided  by  Section  27.410. 


(0  Delivery  of  Technical  Data  to  Foreign  Governments.  As  provided  in  the  definition  of 
limited  rights  in  Section  27.401,  limited  rights  include  the  right  of  the  Government  to  deliver 
the  technical  data  to  foreign  governments  as  the  national  interest  of  the  United  States  may 
require,  subject  to  the  same  limitations  which  the  Government  accepts  for  itself.  When  the 
Government  proposes  to  make  technical  data  subject  to  limited  rights  available  for  use  by  a 
foreign  government,  it  will,  to  the  maximum  extent  practicable,  give  reasonable  notice  thereof 
to  the  contractor  or  subcontractor  who  generated  the  technical  data  and  whose  name 
appears  thereon.  27.404  Acquisition  of  Rights  in  Computer  Software. 


27.404-1  Policy. 


(a)  The  Government  shall  have  unlimited  rights  in: 
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(1)  Computer  software  resulting  directly  from  or  generated  as  part  of  the  performance 
of  experimental,  developmental,  or  research  work  specified  as  an  element  of  performance  in 
a  Government  contract  or  subcontract; 

(2)  Computer  software  required  to  be  originated  or  developed  under  a  Government 
contract,  or  generated  as  a  necessary  part  of  performing  a  contract; 

(3)  Computer  data  bases,  prepared  under  a  Government  contract,  consisting  of-- 

(i)  information  supplied  by  the  Govemment- 

(ii)  information  in  which  the  Government  has  unlimited  rights,  or- 

(iii)  information  which  is  in  the  public  domain; 

(4)  Computer  software  prepared  or  required  to  be  delivered  under  this  or  any  other 
Government  contract  or  subcontract  and  constituting  corrections  or  changes  to  Government- 
furnished  software;  or 

(5)  Computer  software  which  is  in  the  public  domain  or  has  been  or  is  normally 
furnished  by  the  contractor  or  subcontractor  without  restriction. 

(b)  When  the  Government  has  unlimited  rights  in  computer  software  in  the  possession 
of  a  contractor,  no  payment  will  be  made  for  rights  of  use  of  such  software  in  performance  of 
Government  contracts  or  for  the  later  delivery  to  the  Government  of  such  computer  software, 
provided  however,  that  the  contractor  shall  be  entitled  to  compensation  for  converting  the 
software  into  the  preserved  form  for  reproduction  and  delivery  to  the  Government. 

(c)  It  is  Department  of  Defense  policy  to  acquire  only  such  rights  to  use,  duplicate,  and 
disclose  computer  software  developed  at  private  expense  as  are  necessary  to  meet 
Government  needs.  Such  rights  should  be  designed  to  allow  the  Government  flexibility  while, 
at  the  same  time,  adequately  preserving  the  rights  of  the  contractor.  Computer  software 
developed  at  pr  'ate  expense  may  be  purchased  or  leased.  Restrictions  may  be  negotiated 
with  respect  to  ti.e  right  of  the  Government  to  use,  duplicate,  or  disclose  computer  programs 
or  computer  data  bases  developed  at  private  expense.  As  a  minimum,  however,  the 
Government  shall  have  the  rights  provided  in  the  definition  of  restricted  rights  in  Section 
27.401. 

(d)  Patented  or  copyrighted  computer  software  will  not  be  subject  to  any  agreement 
prohibiting  the  Government  from  infringing  a  patent  or  copyright.  Title  28,  United  States 
Code,  Section  1498  provides  that  the  Government  is  liable  only  for  reasonable  compensation 
for  use  of  a  patented  invention  or  for  infringement  of  copyright.  However,  see  Section 
27.711. 

(e)  Wren  computer  software  is  developed  at  private  expense  and  acquired  with 
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restricted  rights,  the  associated  computer  software  documentation  will  be  acquired  with 
limited  rights  to  the  extent  provided  in  the  definition  of  limited  rights  in  Section  27.401,  and 
will  not  be  used  for  preparing  the  same  or  similar  computer  software. 


(0  Commercial  computer  software  and  related  documentation  developed  at  private 
expense  may  be  leased,  or  a  license  to  use  may  be  purchased,  by  the  Government  subject  to 
the  restrictions  in  subdivision  (b)(3)(i)  of  the  clause  at  52.227-7013,  Rights  in  Technical  Data 
and  Computer  Software. 


27.404-2  Procedures. 


(a)  Deviations.  All  requests  for  deviations  from  this  Section  27.404  shall  be  submitted 
to  the  DAR  Council  in  accordance  with  the  procedures  in  FAR  Section  1 .404. 


(b)  General. 


(1)  except  as  provided  at  52.227-7031,  Data  Requirements,  any  computer  program  or 
computer  data  base  to  be  purchased  under  a  contract  shall  be  listed  on  the  Contract  Data 
Requirements  List  (DD  Form  1423).  Also,  if  a  contract  requires  the  conversion  of  data  to 
machine-readable  form,  the  editing  or  revision  of  existing  programs,  or  the  preparation  of 
computer  software  documentation,  the  products  of  this  work,  if  required  to  be  delivered,  shall 
be  included  on  the  DD  Form  1423. 


(2)  The  clause  at  52.227-7013,  Rights  in  Technical  Data  and  Computer  Software,  shall 
be  included  in  every  contract  under  which  computer  software  may  be  originated,  developed, 
or  delivered.  That  clause  establishes  the  circumstances  under  which  the  Government 
secures  unlimited  rights  in  both  technical  data  and  computer  software,  limited  rights  in 
technical  data,  and  restricted  rights  in  computer  software.  In  negotiated  contracts  where  the 
clause  at  52.227-7013,  Rights  in  Technical  Data  and  Computer  Software,  is  required,  the 
provision  at  52.227-7019,  Identification  of  Restricted  Rights  Computer  Software,  shall  be 
included  in  the  solicitation. 


(3)  Contracts  under  which  computer  software  developed  at  private  expense  is  procured 
cr  leased  shall  explicitly  set  forth  the  rights  necessary  to  meet  Government  needs  and 
restrictions  applicable  to  the  Government  as  to  use,  duplication  and  disclosure  of  the 
software.  Thus,  for  example,  such  software  may  be  needed,  or  the  owner  of  such  software 
will  only  sell  or  lease  it,  for  specific  or  limited  purposes  such  as  for  internal  agency  use,  or  for 
use  in  a  specific  activity,  installation  or  service  location.  In  any  event,  the  contract  must 
clearly  define  any  restrictions  on  the  right  of  the  Government  to  use  such  computer  software, 
but  such  restrictions  will  be  acceptable  only  if  they  will  permit  the  Government  to  fulfill  the 
need  for  which  such  software  is  being  procured.  The  recital  of  restrictions  may  be  complete 
within  itself  or  it  may  reference  the  contractor's  license  or  other  agreement  setting  forth 
restrictions.  If  referencing  is  employed,  a  copy  of  the  license  or  agreement  must  be  attached 
to  the  contract.  The  minimum  rights  are  provided  in  the  Rights  in  Technical  Data  and 
Computer  Software  clause  at  52.227-7013,  and  need  not  be  included  in  the  recital. 


(4)  When  computer  software  developed  at  private  expense  is  modified  or  enhanced  as 
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a  necessary  part  of  performing  a  contract,  only  that  portion  of  the  resulting  product  in  which 
the  original  product  is  recognizable  will  be  deemed  to  be  computer  software  developed  at 
private  expense  to  which  restricted  rights  may  attach. 

(5)  The  scope  of  the  restrictions  on  or,  conversely,  the  scope  of  the  use  which  the 
Government  is  permitted  to  make  of  such  software  shall  be  taken  into  account  in  determining 
the  reasonableness  of  the  contract  price  for  the  computer  software. 

(c)  Computer  Software  Subject  to  Restricted  Rights. 


(1)  Because  of  the  widely-varying  restrictions  which  are  likely  to  be  encountered  in  the 
purchase  or  lease  of  computer  software  developed  at  private  expense,  a  standard  recital 
setting  forth  specific  restrictions  and  rights  suitable  for  all  cases  is  not  feasible.  If  the 
standard  set  of  restrictions  and  rights  set  forth  in  paragraph  27.404-l(f)  for  commercial 
computer  software  is  not  appropriate,  personnel  are  urged  to  consult  counsel  in  any  case  in 
which  the  proposed  contractor  requests  the  Government  to  accept  other  restrictions  on  the 
use  of  such  software. 


(2)  To  apprise  user  personnel  of  the  restrictions  on  use,  duplication  or  disclosure 
agreed  to  by  the  Government  with  respect  to  such  software  sold  or  leased  to  the 
Government,  the  contractor  is  required  to  place  the  following  legend  on  such  software: 

RESTRICTED  RIGHTS  LEGEND 

Use,  duplication  or  disclosure  is  subject  to 

restrictions  stated  in  Contract  No . 

with . (Name  of  Contractor). 


For  commercial  computer  software  and  documentation,  the  contract  number  may  be 
omitted  and  replaced  by  ’paragraph  (b)(3)(B)  of  the  Rights  in  Technical  Data  and  Computer 
Software  clause  at  52.227-7013’,  and  the  contractor's  address  added.  The  Government  shall 
include  the  same  restrictive  markings  on  all  its  reproductions  of  the  computer  software  unless 
the  Government  cancels  such  markings  pursuant  to  the  procedures  in  Paragraph 
27.403-3(d). 

(3)  A  statement  setting  forth  the  restrictions  imposed  on  the  Government  to  use. 
duplicate,  and  disclose  computer  software  subject  to  restricted  rights  is  required  to  be 
prominently  displayed  in  human-  readable  form  in  the  computer  software  documentation. 
The  reference  to  the  Rights  in  Technical  Data  and  Computer  Software  clause  in  the 
Restricted  Rights  Legend  on  commercial  computer  software  and  documentation  satisfies  this 
requirement. 


(4)  Except  as  provided  in  paragraph  (b)  above,  computer  programs,  computer  data 
bases,  and  computer  software  documentation  delivered  to  the  Government  pursuant  to  a 
contract  requirement  must  be  identified  with  the  number  of  the  prime  contract  and  the  name 
of  the  contractor. 


(5)  All  markings,  (notice,  legends,  identifications,  etc.)  concerning  restrictions  on  the 
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use,  duplication,  or  disclosure  of  computer  software  required  or  authorized  by  the  terms  of 
the  contract  under  which  delivery  is  made  are  required  to  be  in  human-readable  form  that  can 
be  readily  and  visually  perceived  and,  in  addition  may  be  in  machine-readable  form  as 
appropriate  and  feasible  under  the  circumstances.  Such  markings  shall  be  affixed  by  the 
contractor  to  the  computer  software  prior  to  delivery  of  the  software  to  the  Government. 


(6)  The  human-readable  markings  may  be  applied  to  card  decks,  magnetic  tape  reels, 
or  disc  packs.  This  may  be,  in  the  case  of  a  card  deck,  on  a  notice  card  even  though  the 
cards  of  the  deck  do  not  contain  printed  material;  in  the  case  of  a  card  deck  packaged  in  a 
container  intended  as  a  permanent  receptacle  for  the  cards,  on  the  container;  in  the  case  of  a 
tape,  on  the  tape  reel  or  on  the  surface  of  the  leader  and  trailer  of  the  tape;  and  in  the  case  of 
a  disc  pack,  on  the  hub  of  the  disc. 


(d)  Unmarked  or  Improperly  Marked  Computer  Software. 


(1)  No  restrictive  markings  shall  be  placed  upon  computer  software  unless  restrictions 
are  set  forth  in  the  contract  prior  to  delivery  of  the  software.  Copyright  notices  as  specified  in 
Title  17,  United  States  Code,  Sections  401  and  402  are  not  considered  'restrictive  markings*. 
The  Government  may  require  the  contractor  to  identify  the  contractual  provision  setting  forth 
such  restrictions  before  accepting  computer  software  with  restrictive  markings.  If  computer 
software  is  received  with  restrictive  markings,  and  there  is  a  question  whether  it  is  authorized 
by  the  contract  to  be  furnished  with  restricted  rights,  it  shall  be  used  subject  to  the  asserted 
restrictions  pending  written  inquiry  to  the  contractor.  If  no  response  to  an  inquiry  has  been 
received  within  60  days,  or  if  the  response  fails  to  identify  the  restrictions  set  forth  in  the 
contract,  the  cognizant  Government  personnel  shall  cancel  or  ignore  the  markings,  notify  the 
contractor  accordingly  in  writing,  and  thereafter  use  the  software  with  unlimited  rights. 


(2)  Computer  software  received  without  a  restrictive  legend  shall  be  deemed  to  have 
been  furnished  with  unlimited  rights.  However,  the  contractor  may  request  permission  to 
place  restrictive  markings  on  such  software  at  his  own  expense,  and  the  Government  may  so 
permit,  if  the  contractor  establishes  that  the  markings  are  authorized  by  the  contract  and 
demonstrates  that  the  omission  was  inadvertent.  Failure  of  the  contractor  to  mark  such 
computer  software  prior  to  delivery  to  the  Government  shall  relieve  the  Government  of  liability 
for  any  use,  duplication  or  disclosure  of  such  computer  software. 


(3)  If  computer  software  authorized  by  the  contract  to  be  furnished  with  restrictions  is 
received  with  restrictive  markings  not  in  the  form  prescribed  by  the  contract,  the  software 
should  be  used  in  accordance  with  the  restrictions  provided  for  in  the  contract  and  the 
contractor  shall  be  required  by  written  notice  to  correct  the  markings  to  conform  with  those 
specified  in  the  contract.  If  the  contractor  fails  to  correct  the  markings  within  60  days  after 
notice,  Government  personnel  may  correct  the  markings,  and  so  notify  the  contractor. 


DoD  FAR  SUPPLEMENT  150 


D  AC  #84-1, 1  March  1984 


52.227-7013  Rights  in  Technical  Data  and  Computer  Software.  As  prescribed  at 
27.412(a)(1),  insert  the  following  clause: 


RIGHTS  IN  TECHNICAL  DATA  AND  COMPUTER  SOFTWARE  (MAY  1981) 


(a)  Definitions.  “Commercial  Computer  Software’,  as  used  in  this  clause,  means 
computer  software  which  is  used  regularly  for  other  that  government  purposes  and  is  sold, 
licensed  or  leased  in  significant  quantities  to  the  general  public  at  established  market  or 
catalog  prices. 


'Computer”,  as  used  in  this  clause,  means  a  data  processing  device  capable  of 
accepting  data,  performing  prescribed  operations  on  a  device  that  operates  on  discrete  data 
by  performing  arithmetic  and  logic  processes  on  the  data,  or  a  device  that  operates  on  analog 
data  by  performing  physical  processes  on  the  data. 


“Computer  Data  Base*,  as  used  in  this  clause,  means  a  collection  of  data  in  a  form 
capable  of  being  processed  and  operated  on  by  a  computer. 


“Computer  Program*,  as  used  in  this  clause,  means  a  series  of  instructions  or 
statements  in  a  form  acceptable  to  a  computer,  designed  to  cause  the  computer  to  execute 
an  operation  or  operations.  Computer  programs  include  operating  systems,  assemblers, 
compilers,  interpreters,  data  management  systems,  utility  programs,  sort-merge  programs, 
and  ADPE  maintenance/diagnostic  programs,  as  well  as  applications  programs  such  as 
payroll,  inventory  control,  and  engineering  analysis  programs.  Computer  programs  may  be 
either  machine-dependent  or  machine-independent,  and  may  be  general-purpose  in  nature  or 
designed  to  satisfy  the  requirements  of  a  particular  user. 


“Computer  Software*,  as  used  in  this  clause,  means  computer  programs  and  computer 
data  bases. 


“Computer  Software  Documentation*,  as  used  in  this  clause,  means  technical  data, 
including  computer  listings  and  printouts,  in  human-  readable  form  which  (1)  documents  the 
design  or  details  of  computer  software,  (2)  explains  the  capabilities  of  the  software,  or  (3) 
provides  operating  instructions  for  using  the  software  to  obtain  desired  results  from  a 
computer. 


“Limited  Rights’*  as  used  in  this  clause,  means  rights  to  use,  duplicate,  or  disclose 
technical  data,  in  whole  or  in  part,  by  or  for  the  Government,  with  the  express  limitation  that 
such  technical  data  shall  not,  without  the  written  permission  of  the  parly  furnishing  such 
technical  data  be  (1)  released  or  disclosed  in  whole  or  in  part  outside  the  Government,  (2) 
used  in  whole  or  in  part  by  the  Government  for  manufacture,  or  in  the  case  of  computer 
software  documentation,  for  preparing  the  same  or  similar  computer  software,  or  (3)  used  by 
a  party  other  than  the  Government,  except  for: 


(1)  Emergency  repair  or  overhaul  work  only,  by  or  for  the  Government,  where  the  item 
or  process  concerned  is  not  otherwise  reasonably  available  to  enable  timely  performance  of 
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(he  work;  Provided,  that  the  release  or  disclosure  thereof  outside  the  Government  shall  be 
made  subject  to  a  prohibition  against  further  use,  release  or  disclosure;  or 

(2)  Release  to  a  foreign  government,  as  the  interest  of  the  United  States  may  require, 
only  for  information  or  evaluation  within  such  government  or  for  emergency  repair  or  overhaul 
work  by  or  for  such  government  under  the  conditions  of  (1)  above. 

"Restricted  Rights",  as  used  in  this  clause,  means  rights  that  apply  only  to  computer 
software,  and  include,  as  a  minimum,  the  right  to-- 

(1)  Use  computer  software  with  the  computer  for  which  or  with  which  it  was  acquired, 
including  use  at  any  Government  installation  to  which  the  computer  may  be  transferred  by  the 
Government; 

(2)  Use  computer  software  with  a  backup  computer  if  the  computer  for  which  or  with 
which  it  was  acquired  is  inoperative; 

(3)  Copy  computer  programs  for  safekeeping  (archives)  or  backup  purposes;  and 

(4)  Modify  computer  software,  or  combine  it  with  other  software,  subject  to  the 
provision  that  those  portions  of  the  derivative  software  incorporating  restricted  rights  software 
are  subject  to  the  same  restricted  rights. 

In  addition,  restricted  rights  include  any  other  specific  rights  not  inconsistent  with  the 
minimum  rights  in  (1)-(4)  above  that  are  listed  or  described  in  this  contract  or  described  in  a 
license  or  agreement  made  a  part  of  this  contract. 

"Technical  Data",  as  used  in  this  clause,  means  recorded  information,  regardless  of 
form  or  characteristic,  of  a  scientific  or  technical  nature,  it  may,  for  example,  document 
research,  experimental,  developmental  or  engineering  work,  or  be  usable  or  used  to  define  a 
design  or  process  or  to  procure,  produce,  support,  maintain,  or  operate  materiel.  The  data 
may  be  graphic  or  pictorial  delineations  in  media  such  as  drawings  or  photographs,  text  in 
specifications  or  related  performance  or  design  type  documents,  or  computer  printouts. 
Examples  of  technical  data  include  research  and  engineering  data,  engineering  drawings  and 
associated  lists,  specifications,  standards,  process  sheets,  manuals,  technical  reports, 
catalog  item  identifications  and  related  information,  and  computer  software  documentation. 
Technical  data  does  not  include  computer  software  or  financial,  administrative,  cost  and 
pricing,  and  management  data  or  other  information  incidental  to  contract  administration. 

Unlimited  Rights’,  as  used  in  this  clause,  means  rights  to  use,  duplicate,  or  disclose 
technical  data,  in  whole  or  in  part,  in  any  manner  and  for  any  purpose  whatsoever,  and  to 
have  or  permit  others  to  do  so. 

(b)  Government  Rights. 
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(1)  Unlimited  Rights.  The  Government  shall  have  unlimited  rights  in: 


(i)  technical  data  and  computer  software  resulting  directly  from  performance  of 
experimental,  developmental  or  research  work  which  was  specified  as  an  element  of 
performance  in  this  or  any  other  Government  contract  or  subcontract; 


(ii)  computer  software  required  to  be  originated  or  developed  under  a  Government 
contract,  or  generated  as  a  necessary  part  of  performing  a  contract; 


(••'•)  computer  data  bases,  prepared  under  a  Government  contract,  consisting  of 
information  supplied  by  the  Government,  information  in  which  the  Government  has  unlimited 
rights,  or  information  which  is  in  the  public  domain; 


(iv)  technical  data  necessary  to  enable  manufacture  of  end-items,  components,  and 
modifications,  or  to  enable  the  performance  of  processes,  when  the  end-items,  components, 
modifications  or  processes  have  been,  or  are  being,  developed  under  this  or  any  other 
Government  contract  or  subcontract  in  which  experimental,  developmental  or  research  work 
is,  or  was  specified  as  an  element  of  contract  performance,  except  technical  data  pertaining 
to  items,  components,  processes,  or  computer  software  developed  at  private  expense  (but 
see  subdivision  (b)(2)(ii)  below); 


(v)  technical  data  or  computer  software  prepared  or  required  to  be  delivered  under  this 
or  any  other  Government  contract  or  subcontract  and  constituting  corrections  or  changes  to 
Government-  furnished  data  or  computer  software; 


(vi)  technical  data  pertaining  to  end-items;  components  or  processes,  prepared  or 
required  to  be  delivered  under  this  or  any  other  Government  contract  or  subcontract,  for  the 
purpose  of  identifying  sources,  size,  configuration,  mating  and  attachment  characteristics, 
functional  characteristics  and  performance  requirements  (“form,  fit  and  function"  data,  e  g., 
specification  control  drawings,  catalog  sheets,  envelope  drawings,  etc.); 


(vii)  manuals  or  instructional  materials  prepared  or  required  to  be  delivered  under  this 
contract  or  any  subcontract  hereunder  for  installation,  operation,  maintenance  or  training 
purposes; 


(viii)  technical  data  or  computer  software  which  is  in  the  public  domain,  or  has  been  or 
is  normally  released  or  disclosed  by  the  Contractor  or  subcontractor  without  restriction  on 
further  disclosure;  and 


(ix)  technical  data  or  computer  software  listed  or  described  in  an  agreement 
incorporated  into  the  schedule  of  this  contract  which  the  parties  have  predetermined,  on  the 
basis  of  subparagraphs  (i)  through  (viii)  above,  and  agreed  will  be  furnished  with  unlimited 
rights. 


(2)  Limited  Rights.  The  Government  shall  have  limited  rights  in:. 
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(i)  technical  data,  listed  or  described  in  an  agreement  incorporated  into  the  Schedule  of 
this  contract,  which  the  parties  have  agreed  will  be  furnished  with  limited  rights;  and 


(ii)  unpublished  technical  data  pertaining  to  items,  components  or  processes  developed 
at  private  expense,  and  unpublished  computer  software  documentation  related  to  computer 
software  that  is  acquired  with  restricted  rights,  other  than  such  data  as  may  be  included  in  the 
data  referred  to  in  subdivisions  (b)(i)(i),  (v),  (vi),  (vii),  and  (viii)  above.  The  word  unpublished, 
as  applied  to  technical  data  and  computer  software  documentation,  means  that  which  has  not 
been  released  to  the  public  nor  been  furnished  to  others  without  restriction  on  further  use  or 
disclosure.  For  the  purpose  of  this  definition,  delivery  of  limited  rights  technical  data  to  or  for 
the  Government  under  a  contract  does  not,  in  itself,  constitute  release  to  the  public. 


Limited  rights  shall  be  effective  provided  that  only  the  portion  or  portions  of  each  piece 
of  data  to  which  limited  rights  are  to  be  asserted  pursuant  to  subdivisions  (2)(i)  and  (ii)  above 
are  identified  (for  example,  by  circling,  underscoring,  or  a  note),  and  that  the  piece  of  data  is 
marked  with  the  legend  below  in  which  is  inserted: 


A.  the  number  of  the  prime  contract  under  which  the  technical  data  is  to  be  delivered, 


B.  the  name  of  the  Contractor  and  any  subcontractor  by  whom  the  technical  data  was 
generated,  and 

C.  an  explanation  of  the  method  used  to  identify  limited  rights  data. 

LIMITED  RIGHTS  LEGEND 

Contract  No. - 

Contractor: 


Explanation  of  Limited  Rights  Data  Identification  Method  Used 

Those  portions  of  this  technical  data  indicated  as  limited  rights  data  shall  not,  without 
the  written  permission  of  the  above  Contractor,  be  either 

(A)  used,  released  or  disclosed  in  whole  or  in  part  outside  the  Government, 


(B)  used  in  whole  or  in  part  by  the  Government  for  manufacture  or,  in  the  case  of 
computer  software  documentation,  for  preparing  the  same  or  similar  computer  software,  or 

(C)  used  by  a  party  other  than  the  Government,  except  for: 


(1)  emergency  repair  or  overhaul  work  only,  by  or  for  the  Government,  where  the  item 
or  process  concerned  is  not  otherwise  reasonably  available  to  enable  timely  performance  of 
the  work,  Provided,  that  the  release  or  disclosure  hereof  outside  the  Government  shall  be 
made  subject  to  a  prohibition  against  further  use,  release  or  disclosure;  or 
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(2)  release  to  a  foreign  government,  as  the  interest  of  the  United  States  may  require, 
only  for  information  or  evaluation  within  such  government  or  for  emergency  repair  or  overhaul 
work  by  or  for  such  government  under  the  conditions  of  (1)  above.  This  legend,  together  with 
the  indications  of  the  portions  of  this  data  which  are  subject  to  such  limitations  shall  be 
included  on  any  reproduction  hereof  which  includes  any  part  of  the  portions  subject  to  such 
limitations. 


(3)  Restricted  Rights. 

(i)  The  Government  shall  have  restricted  rights  in  computer  software,  listed  or 
described  in  a  license  or  agreement  made  a  part  of  this  contract,  which  the  parties  have 
agreed  will  be  furnished  with  restricted  rights,  Provided,  however,  notwithstanding  any 
contrary  provision  in  any  such  license  or  agreement,  the  Government  shall  have  the  rights 
included  in  the  definition  of  "restricted  rights"  in  paragraph  (a)  above.  Such  restricted  rights 
are  of  no  effect  unless  the  computer  software  is  marked  by  the  Contractor  with  the  following 
legend:. 

RESTRICTED  RIGHTS  LEGEND 
Use,  duplication  or  disclosure  is  subject  to 
restrictions  stated  In  Contract  No. 
with  (Name  of  Contractor) 


and  the  related  computer  software  documentation  includes  a  prominent  statement  of 
the  restrictions  applicable  to  the  computer  software.  The  Contractor  may  not  place  any 
legend  on  computer  software  indicating  restrictions  on  the  Government’s  rights  in  such 
software  unless  the  restrictions  are  set  forth  in  a  license  or  agreement  made  a  part  of  this 
contract  prior  to  the  delivery  date  of  the  software.  Failure  of  the  Contractor  to  apply  a 
restricted  rights  legend  to  such  computer  software  shall  relieve  the  Government  of  liability 
with  respect  to  such  unmarked  software. 


(ii)  Notwithstanding  subdivision  (i)  above,  commercial  computer  software  and  related 
documentation  developed  at  private  expense  and  not  in  public  domain  may,  if  the  Contractor 
so  elects,  be  marked  with  the  following  Legend: 

RESTRICTED  RIGHTS  LEGEND 

Use,  duplication,  or  disclosure  of  the 

Government  is  subject  to  restrictions 

as  set  forth  in  subdivision  (b 


(3)(ii)  of) 

the  Rights  in  Technical  Data  and  Computer 
Software  clause  at  52.227*7013. 
(Name  of  Contractor  and  Address) 


When  acquired  by  the  Government,  commercial  computer  software  and  related 
documentation  so  legended  shall  be  subject  to  the  following: 
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(A)  Title  to  and  ownership  of  the  software  and  documentation  shall  remain  with  the 
Contractor. 


(B)  User  of  the  software  and  documentation  shall  be  limited  to  the  facility  for  which  it  is 
acquired. 


(C)  The  Government  shall  not  provide  or  otherwise  make  available  the  software  or 
documentation,  or  any  portion  thereof,  in  any  form,  to  any  third  party  without  the  prior  written 
approval  of  the  Contractor. 


Third  parties  do  not  include  prime  contractors,  subcontractors  and  agents  of  the 
Government  who  have  the  Government's  permission  to  use  the  licensed  software  and 
documentation  at  the  facility,  and  who  have  agreed  to  use  the  licensed  software  and 
documentation  only  in  accordance  with  these  restrictions.  This  provision  does  not  limit  the 
right  of  the  Government  to  use  software,  documentation,  or  information  therein,  which  the 
Government  may  already  have  or  obtains  without  restrictions. 


(D)  The  Government  shall  have  the  right  to  use  the  computer  software  and 
documentation  with  the  computer  for  which  it  is  acquired  at  any  other  facility  to  which  that 
computer  may  be  transferred;  to  use  the  computer  software  and  documentation  with  a 
backup  computer  when  the  primary  computer  is  inoperative;  to  oopy  computer  programs  for 
safekeeping  (archives)  or  backup  purposes;  and  to  modify  the  software  and  documentation  or 
combine  it  with  other  software,  Provided,  that  the  unmodified  portions  shall  remain  subject  to 
these  restrictions. 


(E)  If  the  Contractor,  within  sixty  (60)  days  after  a  written  request,  fails  to  substantiate 
by  clear  and  convincing  evidence  that  computer  software  and  documentation  marked  with  the 
above  Restricted  Rights  Legend  are  commercial  items  and  were  developed  at  private 
expense,  or  if  the  Contractor  fails  to  refute  evidence  which  is  asserted  by  the  Government  as 
a  basis  that  the  software  is  in  the  public  domain,  the  Government  may  cancel  or  ignore  any 
restrictive  markings  on  such  computer  software  and  documentation  and  may  use  them  with 
unlimited  rights.  Such  written  requests  shall  be  addressed  to  the  Contractor  as  identified  in 
the  Restricted  Rights  Legend. 


(4)  No  legend  shall  be  marked  on,  nor  shall  any  limitation  or  restriction  on  rights  of  use 
be  asserted  as  to,  any  data  or  computer  software  which  the  Contractor  has  previously 
delivered  to  the  Government  without  restriction.  The  limited  or  restricted  rights  provided  for 
by  this  paragraph  shall  not  impair  the  right  of  the  Government  to  use  similar  or  identical  data 
or  computer  software  acquired  from  other  sources. 


(c)  Copyright. 

(1)  In  addition  to  the  rights  granted  under  the  provisions  of  paragraph  (b)  above,  the 
Contractor  hereby  grants  to  the  Government  a  nonexclusive,  paid-up  license  throughout  the 
world,  of  the  scope  set  forth  below,  under  any  copyright  owned  by  the  Contractor,  in  any  work 
of  authorship  prepared  for  or  acquired  by  the  Government  under  this  contract,  to  reproduce 
the  work  in  copies  or  phonorecords,  to  distribute  copies  or  phonorecords  to  the  public,  to 
perform  or  display  the  work  publicly,  and  to  prepare  derivative  works  thereof,  and  to  have 
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others  do  so  for  Government  purposes.  With  respect  to  technical  data  and  computer 
software  in  which  the  Government  has  unlimited  rights,  the  license  shall  be  of  the  same 
scope  as  the  rights  set  forth  in  the  definition  of  'unlimited  rights"\in  paragraph  (a)  above.  With 
respect  to  technical  data  in  which  the  Government  has  limited  rights,  the  scope  of  the  license 
is  limited  to  the  rights  set  forth  in  the  definition  of  ’limited  rights*  in  paragraph  (a)  above.  With 
respect  to  computer  software  which  the  parties  have  agreed  in  accordance  with 
subparagraph  (b)(3)  above  will  be  furnished  with  restricted  rights,  the  scope  of  the  license  is 
limited  to  such  rights. 

(2)  Unless  written  approval  of  the  Contracting  Officer  is  obtained,  the  Contractor  shall 
not  include  in  technical  data  or  computer  software  prepared  for  or  acquired  by  the 
Government  under  this  contract  any  works  of  authorship  in  which  copyright  is  not  owned  by 
the  Contractor  without  acquiring  for  the  Government  any  rights  necessary  to  perfect  a 
copyright  license  of  the  scope  specified  in  subparagraph  (c)(1). 

(3)  As  between  the  Contractor  and  the  Government,  the  Contractor  shall  be  considered 
the  ’person  for  whom  the  work  was  prepared  for  the  purpose  of  determining  authorship  under 
Section  201(b)  of  Title  17,  United  States  Code. 

(4)  Technical  data  delivered  under  this  contract  which  carries  a  copyright  notice  shall 
also  include  the  following  statement  which  shall  be  placed  thereon  by  the  Contractor,  or 
should  the  Contractor  fail,  by  the  Government:. 

This  material  may  be  reproduced  by  or  for  the  U.S.  Government  pursuant  to  the  copyright 
license  under  the  clause  at  52.227-7013  (date). 

(d)  Removal  of  Unauthorized  Markings.  Notwithstanding  any  provision  of  this  contract 
concerning  inspection  and  acceptance,  the  Government  may  correct,  cancel,  or  ignore  any 
marking  not  authorized  by  the  terms  of  this  contract  on  any  technical  data  or  computer 
software  furnished  hereunder  if: 

(1)  the  Contractor  fails  to  respond  within  sixty  (60)  days  to  a  written  inquiry  by  the 
Government  concerning  the  propriety  of  the  markings,  or 

(2)  the  Contractor's  response  fails  to  substantiate,  within  sixty  (60)  days  after  written 
notice,  the  propriety  of  limited  rights  markings  by  clear  and  convincing  evidence,  or  of 
restricted  rights  markings  by  identification  of  the  restrictions  set  forth  in  the  contract. 

In  either  case,  the  Government  shall  give  written  notice  to  the  Contractor  of  the  action 


(e)  Relation  to  Patents.  Nothing  contained  In  this  clause  shall  imply  a  license  to  the 
Government  under  any  patent  or  be  construed  as  affecting  the  scope  of  any  license  or  other 
right  otherwise  granted  to  the  Government  under  any  patent. 

(f)  Limitation  on  Charges  for  Data  and  Computer  Software.  The  Contractor  reoognizes 
that  the  Government  or  a  foreign  government  with  funds  derived  through  the  Military 
Assistance  Program  or  otherwise  through  the  United  States  Government  may  contract  for 
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property  or  services  with  respect  to  which  the  vendor  may  be  liable  to  the  Contractor  for 
charges  for  the  use  of  technical  data  or  computer  software  on  account  of  such  a  contract. 
The  Contractor  further  recognizes  that  it  is  the  policy  of  the  Government  not  to  pay  in 
connection  with  its  contracts,  or  to  allow  to  be  paid  in  connection  with  contracts  made  with 
funds  derived  through  the  Military  Assistance  Program  or  otherwise  through  the  United  States 
Government,  charges  for  data  or  computer  software  which  the  Government  has  a  right  to  use 
and  disclose  to  others,  which  is  in  the  public  domain,  or  which  the  Government  has  been 
given  without  restrictions  upon  its  use  and  disclosure  to  others.  This  policy  does  not  apply  to 
reasonable  reproduction,  handling,  mailing,  and  similar  administrative  costs  incident  to  the 
furnishing  of  such  data  or  computer  software.  In  recognition  of  this  policy,  the  Contractor 
agrees  to  participate  in  and  make  appropriate  arrangements  for  the  exclusion  of  such 
charges  from  such  contracts,  or  for  the  refund  of  amounts  received  by  the  Contractor  with 
respect  to  any  such  charges  not  so  excluded. 


(g)  Acquisition  of  Data  and  Computer  Software  from  Subcontractors. 


(1)  Whenever  any  technical  data  or  computer  software  is  to  be  obtained  from  a 
subcontractor  under  this  contract,  the  Contractor  shall  use  this  same  clause  in  the 
subcontract,  without  alteration,  and  no  other  clause  shall  be  used  to  enlarge  or  diminish  the 
Government’s  or  the  Contractor's  rights  in  that  subcontractor  data  or  computer  software 
which  is  required  for  the  Government. 


(2)  Technical  data  required  to  be  delivered  by  a  subcontractor  shall  normally  be 
delivered  to  the  next-higher  tier  contractor.  However,  when  there  is  a  requirement  in  the 
prime  contract  for  data  which  may  be  submitted  with  limited  rights  pursuant  to  subparagraph 
(b)(2)  above,  a  subcontractor  may  fulfill  such  requirement  by  submitting  such  data  directly  to 
the  Government  rather  than  through  the  prime  Contractor. 


(3)  The  Contractor  and  higher-tier  subcontractors  will  not  use  their  power  to  award 
subcontracts  as  economic  leverage  to  acquire  rights  in  technical  data  or  computer  software 
from  their  subcontractors  for  themselves. 

(End  of  clause) 


ALTERNATE  I  (MAY  1981)  As  prescribed  at  27.412(a)(2),  add  the  following  paragraph  to  the 
basic  clause: 


Notice  of  Certain  Limited  Rights. 


(h)(1)  Unless  the  Schedule  provides  otherwise,  and  subject  to  (2)  below,  the  Contractor 
will  promptly  notify  the  Contracting  Officer  in  writing  of  the  intended  use  by  the  Contractor  or  a 
subcontractor  in  performance  of  this  contract  of  any  item,  component  or  process  for  which 
technical  data  would  fall  within  subparagraph  (b)(2)  above. 


(2)  Such  notification  is  not  required  with  respect  to: 


DoD  FAR  SUPPLEMENT  158 


OAC  #84-7,  IS  August  1984 


(i)  standard  commercial  items  which  are  manufactured  by  more  than  one  source  of 
supply;  or  j 


(ii)  items,  components  or  processes  for  which  such  notice  was  given  pursuant  to 
predetermination  of  rights  in  technical  data  in  connection  with  this  contract. 


(3)  Contracting  Officer  approval  is  not  necessary  under  this  clause  for  the  Contractor  to 
use  the  item,  component  or  process  in  the  performance  of  the  contract. 


ALTERNATE  II  (MAY  1981)  As  prescribed  at  27.412(a)(3),  add  the  following  paragraph  to  the 
basic  clause: 


( )  Publication  for  sale.  If,  prior  to  publication  for  sale  by  the  Government  and  within  the 
period  designated  in  the  contract  or  task  order,  but  in  no  event  later  than  24  months  after 
delivery  of  such  data,  the  Contractor  publishes  for  sale  any  data 


(1)  designated  in  the  contract  as  being  subject  to  this  paragraph  and 


(2)  delivered  under  this  contract,  and  promptly  notifies  the  Contracting  Officer  of  these 
publications,  the  Government  shall  not  publish  such  data  for  sale  or  authorize  others  to  do  so. 
This  limitation  on  the  Government's  right  to  publish  for  sale  any  such  data  so  published  by 
the  Contractor  shall  continue  as  long  as  the  data  is  protected  as  a  published  work  under  the 
copyright  law  of  the  United  States  and  is  reasonably  available  to  the  public  for  purchase.  Any 
such  publication  shall  include  a  notice  identifying  this  contract  and  recognizing  the  license 
rights  of  the  Government  under  subparagraph  (c)(1)  of  this  clause.  As  to  all  such  data  not  so 
published  by  the  Contractor,  this  paragraph  shall  be  of  no  force  or  effect. 


DoD  FAR  SUPPLEMENT  159 


*.v% 


APPENDIX  C 


Interviewees 


Management 

Contracting 

IN 

Admin. 

Taehnleal 

Paraonnal 

Lawyers 

TOTAL 

C-. 

ARMY 

01 

01 

04 

06 

NAVY 

11 

06 

02 

08 

27 

is 

E 

AIR  FORCE 

09 

14 

15 

09 

47 

a*. 

OSD 

01 

03 

04 

K 

M 

DLA 

03 

03 

tai 

P 

STARS 

04 

04 

L 

fc 

O 

TOTAL  DoD 

22 

28 

17 

24 

91 

i 

NASA 

02 

02 

Y 

Industry 

,  _ 

Prlvats 

V 

Practlcs 

04 

03 

11 

18 

!••' 

P 

E 

Acadamlc 

Rasaarch 

04 

02 

06 

R 

►  * 

TOTAL 

26 

36 

17 

39 

117 

PREVIOUS  PAGE 
IS  BLANK 


161 


i*  refort  security  classification 

Unclassified  _ 


Z».  SECURITY  CLASSIFICATION  AUTHORITY 

N/A  _ 


2o.  oeclassification/oownoaaoino  schedule 

N/A  _ 


A  performing  oaoanization  AEFOAT  NUMBEAIS) 
CMU/SEI-86-TR1 


«A  NAME  OF  FEAFOAMING  ORGANIZATION 

Software  Engineering  Inst. 


6c.  AOOAESS  (City.  Stata  and  ZIP  Coda) 

Carnegie-Mellon  University 
Pittsburgh,  PA  15213 


Ba  NAME  OF  FljNOING/SFONSOAING 
ORGANIZATION 

SEI  Joint  Program  Office 


REPORT  DOCUMENTATION  PAGE 


1b.  RESTRICTIVE  MARKINGS 


for  paUbi  ieIkm  and  M Hi 
dUtriba&aa  la  aaBattaA 


S.  MONITORING  ORGANIZATION  REPORT  NUMBER(S) 

ESD-TR-86-202 


7a  NAME  OF  MONITORING  ORGANIZATION 

SEI  Joint  Program  Office  ESD/ALSI 


7b.  AOOAESS  (City.  Stau  and  ZIP  Coda) 

Hanscom  Air  Force  Base 
Hanscom,  MA  01731 


8b.  OFFICE  SYMBOL  ».  PROCUREMENT  INSTRUMENT  IDENTIFICATION  NUMBER 


Ilf  applicable 

ESD/ALSI 


F19628-85-0003 


Sc.  AOORESS  I City .  Stata  and  ZIP  Coda) 

10.  SOURCE  of  FUNOING  NOS. 

HANSCOM 

program 
element  no. 

FROJECT 

NO. 

TASK  | 

NO. 

WORK  UNIT 
NO. 

11.  TITl£  t Include  Security  Clami  fleet  ion  t 

Toward  a  Reform  of  Che  Defense  Department 

63752F  | 

N/A 

N/A 

N/A 

12.  PERSONAL  AUThORISI 

Pamela  Samuelsor 


13a  Tyfe  OF  report 

Final 


13b.  TiMe  COVEAEO 
FROM  _  TO 


IS.  PAGE  COUNT 

164 


cosati  cooes 


FIELD  1  GROUP  I  SUB.  GR 


T 8.  SUBJECT  terms  (Continue  on  reveree  if  neeeeeary  and  identify  by  bloc*  Humbert 


19.  ABSTRACT  /Continue  on  mverte  if  ne ternary  and  identify  by  bloc *  number) 

This  report  of  Che  Software  Licensing  Project  of  the  SEI  catalogues  and  discusses  various 
problems  with  respect  to  DoD  software  procurement  policy,  and  offers  suggestions  as  to  ways 
in  which  the  DoD  could  improve  its  software  acquisition  and  licensing  methodologies.  The 
report  focuses  on  the  software/data  rights  provisions  of  the  DoD  procurement  regulations 
(DoD  FAR  SUPP  Subpart  27.4)  as  they  relate  to  the  Federal  Acquisition  Regulations,  legisla¬ 
tion  regarding  federal  contracting  practices,  intellectual  property  law(i.e.,  copyright  law 
patent  law,  state  trade  secret  law,  trademark  laws,  etc.)  and  general  commercial  practice 
of  the  software  industry.  Particular  attention  has  been  given  to  legal  issues  related  to 
maintenance  and  enhancement  (software  supportability)  concerns,  reusability  and  ocher 
software  modification  issues,  subcontractor  situations  and  the  possibility  of  an  injunction 
issuing  against  the  government  in  certain  situations.  Issues  related  to  significant  DoD 
projects,  such  as  the  development  of  the  Ada  language  system,  are  also  examined.  This 
report  urges  a  reform  of  DoD  policy  with  respect  to  the  acquisition  of  software,  technical 
data  and  documentation,  software  development  tools,  CAD/CAM  programs  and  the  like 


30.  OISTRIBUTION/AVAILABILITY  of  abstract  21.  ABSTRACT  security  CLASSIFICATION 


unclassifieo/unlimiteo  same  as  rft.  C  otic  users  □  Unclassified 


33a  name  OF  RESFONSIBLE  iNOi  VIOual  23b.  TElEFhoNE  NUMBER 

(Include  Area  Code) 


1 22c.  office  symbol 


00  FORM  1473,  83  APR 


EDITION  of  1  JAN  73  IS  OBSOLETE. 


SECURITY  CLASSIFICATION  OF  THIS  PAGE 


